[RFC][PATCH] Transparent network support through polypaudio

[RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

(Repost with attachment as link to avoid size restriction.)

Hi!

I've implemented an ALSA plugin that allows any well-behaved ALSA 
application transparently use the Polypaudio network protocol.

It is my desire to have this included in ALSA (-lib preferably) so that 
it will be included in most dists. So I'm posting this first version for 
review. :)

It only supports playback at the moment. Polypaudio will undergo some 
changes to allow a capture implementation, but that's not ready yet. 
I'll do a mixer plugin in the coming days.

Some comments on the design. Polypaudio's lib requires a decent mainloop 
abstraction. But ALSA does not force, or even allow, applications to 
provide one (nothing wrong with that, it keeps the API simple). It meant 
a creative solution was required to get this plugin running.

The solution is a design borrowed from the Avahi project. A second 
thread is started that does the poll() call. Communication with the main 
thread is done through a socket pair, and that file descriptor is fed to 
the application to poll. Since some applications do not use these in a 
sane manner (I'm looking at you mplayer) the mainloop abstraction is 
also run on most of the ALSA plugin callbacks.


Code:

http://www.cendio.se/~ossman/alsa-polyp-1.0.10.tar.bz2


This is also not a patch per se, but I needed some tag to get people to 
notice that code is included. :)

You will need to check out polypaudio from svn to compile and use this. 
Also, the repository path on polypaudio's web page is out of date. This 
is the current uri:

svn://svn.0pointer.de/polypaudio/trunk

-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Clemens Ladisch]

Pierre Ossman wrote:
> I've implemented an ALSA plugin that allows any well-behaved ALSA 
> application transparently use the Polypaudio network protocol.
> 
> It is my desire to have this included in ALSA (-lib preferably) so that 
> it will be included in most dists.

It's dependent on polypaudio, so it should better go into the
alsa-plugins package.

> Some comments on the design. Polypaudio's lib requires a decent mainloop 
> abstraction. But ALSA does not force, or even allow, applications to 
> provide one (nothing wrong with that, it keeps the API simple).

A basic assumptions is that a PCM device runs 'by itself'.

> The solution is a design borrowed from the Avahi project. A second 
> thread is started that does the poll() call. Communication with the main 
> thread is done through a socket pair, and that file descriptor is fed to 
> the application to poll.

The dmix plugin does it in a similar way.

> Since some applications do not use these in a sane manner

Nothing in the ALSA API requires applications to use poll() (or to use
blocking writes).

> (I'm looking at you mplayer)

And you're speaking with mplayer's ALSA driver maintainer.
Is there anything wrong with mplayer?  ;-)

> the mainloop abstraction is also run on most of the ALSA plugin
> callbacks.

When an applicatioh disables the stop_threshold, the device is supposed
to continue playing with the current buffer contents (which _is_ a
rather extreme case).

I think you may be required to use a timer for the mainloop.  What does
polypaudio actually do in this callback?  How often must it be called?


Regards,
Clemens


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

Clemens Ladisch wrote:
> Pierre Ossman wrote:
> 
>>I've implemented an ALSA plugin that allows any well-behaved ALSA 
>>application transparently use the Polypaudio network protocol.
>>
>>It is my desire to have this included in ALSA (-lib preferably) so that 
>>it will be included in most dists.
> 
> 
> It's dependent on polypaudio, so it should better go into the
> alsa-plugins package.
> 

I suppose. Then it's just the matter of getting that packaged into the 
dists (fedora doesn't).

> 
>>Since some applications do not use these in a sane manner
> 
> 
> Nothing in the ALSA API requires applications to use poll() (or to use
> blocking writes).
> 
> 
>>(I'm looking at you mplayer)
> 
> 
> And you're speaking with mplayer's ALSA driver maintainer.
> Is there anything wrong with mplayer?  ;-)
> 

Technically no. It's just that it does things in way that makes my life 
more difficult. :)

Btw, mplayer seems to call snd_pcm_prepare() twice. Not sure if that's 
valid behaviour.

> 
>>the mainloop abstraction is also run on most of the ALSA plugin
>>callbacks.
> 
> 
> When an applicatioh disables the stop_threshold, the device is supposed
> to continue playing with the current buffer contents (which _is_ a
> rather extreme case).
> 

The ring buffer design is very difficult to emulate when you have a 
simple queue. Since few (if any) application will rely on this 
behaviour, I've decided to ignore it for now.

> I think you may be required to use a timer for the mainloop.  What does
> polypaudio actually do in this callback?  How often must it be called?
> 

Primarily updates to available buffer space on the server. As for how 
often, I don't really know. Once every period would be a safe guess.

A timer wouldn't be that easy to implement. I want to avoid putting more 
stuff in another thread since the current solution allows me to avoid locks.

Rgds
-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Clemens Ladisch]

Pierre Ossman wrote:
> Clemens Ladisch wrote:
> >Pierre Ossman wrote:
> Btw, mplayer seems to call snd_pcm_prepare() twice.

Not anymore.

> Not sure if that's valid behaviour.

It is.

> >When an applicatioh disables the stop_threshold, the device is supposed
> >to continue playing with the current buffer contents (which _is_ a
> >rather extreme case).
> 
> The ring buffer design is very difficult to emulate when you have a 
> simple queue. Since few (if any) application will rely on this 
> behaviour, I've decided to ignore it for now.

I don't know of any application that actually relies on this.

> >I think you may be required to use a timer for the mainloop.  What does
> >polypaudio actually do in this callback?  How often must it be called?
> 
> Primarily updates to available buffer space on the server.

Shouldn't the data be sent as early as possible, i.e., directly after
the snd_pcm_write() or snd_mmap_commit()?


Regards,
Clemens


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

Clemens Ladisch wrote:
> Pierre Ossman wrote:
> 
>>Clemens Ladisch wrote:
>>
>>>I think you may be required to use a timer for the mainloop.  What does
>>>polypaudio actually do in this callback?  How often must it be called?
>>
>>Primarily updates to available buffer space on the server.
> 
> 
> Shouldn't the data be sent as early as possible, i.e., directly after
> the snd_pcm_write() or snd_mmap_commit()?
> 

I believe it does. What I meant was that the server reports back as it 
consumes the buffer in the other end. That allows us to check available 
space without a round trip to the server.

Rgds
-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

latency issue with mplayer ALSA plugin

[Thierry Vignaud]

Clemens Ladisch <clemens@ladisch.de> writes:

> And you're speaking with mplayer's ALSA driver maintainer.

is that so :-) ?

since we switched from pre7 to cvs (currently 20051220), i find
mplayer's ALSA plugin has latency issues (underrun, ...) that he
didn't have before on the same hw (athlon 2000+ with 256Mo ram).



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: latency issue with mplayer ALSA plugin

[Clemens Ladisch]

Thierry Vignaud wrote:
> since we switched from pre7 to cvs (currently 20051220), i find
> mplayer's ALSA plugin has latency issues (underrun, ...) that he
> didn't have before on the same hw (athlon 2000+ with 256Mo ram).

There haven't been any changes in the ALSA plugin between pre7 and that
date that could affect latency.

Anyway, there have quite a few changes two days ago.


HTH
Clemens


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

New version which includes a mixer component:

http://www.cendio.se/~ossman/alsa-polyp-1.0.10-2.tar.bz2

Now who do I poke to get this reviewed and committed? :)

-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

New version again. This time updated to the polypaudio HEAD. This also 
means that there is record support in this version.

http://www.cendio.se/~ossman/alsa-polyp-1.0.10-3.tar.bz2

-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Takashi Iwai]

At Fri, 17 Feb 2006 20:05:17 +0100,
Pierre Ossman wrote:
> 
> New version again. This time updated to the polypaudio HEAD. This also 
> means that there is record support in this version.
> 
> http://www.cendio.se/~ossman/alsa-polyp-1.0.10-3.tar.bz2

Thanks, I merged polyp plugin to alsa-plugins CVS tree now.
Please give a try later (after anon cvs tree is synced).


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

Takashi Iwai wrote:
> At Fri, 17 Feb 2006 20:05:17 +0100,
> Pierre Ossman wrote:
>> New version again. This time updated to the polypaudio HEAD. This also 
>> means that there is record support in this version.
>>
>> http://www.cendio.se/~ossman/alsa-polyp-1.0.10-3.tar.bz2
> 
> Thanks, I merged polyp plugin to alsa-plugins CVS tree now.
> Please give a try later (after anon cvs tree is synced).
> 

Great!

In case you missed it, I also opened a bug for the issue (I wasn't sure 
how your work flow is so I tried all venues ;)). The bug also contains 
an update not posted on the list:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1852

I can generate a diff for you once the anon CVS is updated.

-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Takashi Iwai]

At Tue, 21 Feb 2006 17:38:37 +0100,
Pierre Ossman wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 17 Feb 2006 20:05:17 +0100,
> > Pierre Ossman wrote:
> >> New version again. This time updated to the polypaudio HEAD. This also 
> >> means that there is record support in this version.
> >>
> >> http://www.cendio.se/~ossman/alsa-polyp-1.0.10-3.tar.bz2
> > 
> > Thanks, I merged polyp plugin to alsa-plugins CVS tree now.
> > Please give a try later (after anon cvs tree is synced).
> > 
> 
> Great!
> 
> In case you missed it, I also opened a bug for the issue (I wasn't sure 
> how your work flow is so I tried all venues ;)). The bug also contains 
> an update not posted on the list:
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1852
> 
> I can generate a diff for you once the anon CVS is updated.

Yes, that'll be helpful.

I have currently very little time to look at ALSA MLs and BTS, so
please add me to Cc at the next update.


Thanks,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Takashi Iwai wrote:
> At Tue, 21 Feb 2006 17:38:37 +0100,
> Pierre Ossman wrote:
>>
>> In case you missed it, I also opened a bug for the issue (I wasn't sure 
>> how your work flow is so I tried all venues ;)). The bug also contains 
>> an update not posted on the list:
>>
>> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1852
>>
>> I can generate a diff for you once the anon CVS is updated.
> 
> Yes, that'll be helpful.
> 
> I have currently very little time to look at ALSA MLs and BTS, so
> please add me to Cc at the next update.
> 
> 

It seems your BTS cannot add cc:s, so I'll send you the diff here.

There shouldn't be any more API changes until polypaudio 0.8 that affect 
this plugin. I am working on supporting capture volume and mute 
switches, but that should be a strict addition (i.e. it can wait until 
the next release if things get tight).

-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com

[-- Attachment #2: polyp-update.patch --]
[-- Type: text/x-patch, Size: 2639 bytes --]

? alsa-plugins-1.0.10.tar.bz2
? alsa-plugins-1.0.10.tar.gz
? polyp-update.patch
Index: configure.in
===================================================================
RCS file: /cvsroot/alsa/alsa-plugins/configure.in,v
retrieving revision 1.13
diff -u -r1.13 configure.in
--- configure.in	21 Feb 2006 16:13:57 -0000	1.13
+++ configure.in	22 Feb 2006 09:44:47 -0000
@@ -15,7 +15,7 @@
 PKG_CHECK_MODULES(JACK, jack >= 0.98, [HAVE_JACK=yes], [HAVE_JACK=no])
 AM_CONDITIONAL(HAVE_JACK, test x$HAVE_JACK = xyes)
 
-PKG_CHECK_MODULES(polypaudio, [polyplib polyplib-mainloop], [HAVE_POLYP=yes], [HAVE_POLYP=no])
+PKG_CHECK_MODULES(polypaudio, [polyplib], [HAVE_POLYP=yes], [HAVE_POLYP=no])
 AM_CONDITIONAL(HAVE_POLYP, test x$HAVE_POLYP = xyes)
 
 SAVE_PLUGINS_VERSION
Index: polyp/pcm_polyp.c
===================================================================
RCS file: /cvsroot/alsa/alsa-plugins/polyp/pcm_polyp.c,v
retrieving revision 1.1
diff -u -r1.1 pcm_polyp.c
--- polyp/pcm_polyp.c	21 Feb 2006 16:14:00 -0000	1.1
+++ polyp/pcm_polyp.c	22 Feb 2006 09:44:47 -0000
@@ -210,7 +210,7 @@
 
 	buf = (char *)areas->addr + (areas->first + areas->step * offset) / 8;
 
-    pa_stream_write(pcm->stream, buf, size * pcm->frame_size, NULL, 0);
+    pa_stream_write(pcm->stream, buf, size * pcm->frame_size, NULL, 0, 0);
 
     /* Make sure the buffer pointer is in sync */
     update_ptr(pcm);
@@ -245,7 +245,7 @@
 
 	dst_buf = (char *)areas->addr + (areas->first + areas->step * offset) / 8;
     while (remain_size > 0) {
-        pa_stream_peek(pcm->stream, (void**)&src_buf, &frag_length);
+        pa_stream_peek(pcm->stream, (const void**)&src_buf, &frag_length);
         if (frag_length == 0)
             break;
 
@@ -352,7 +352,7 @@
     assert(pcm->stream);
 
     if (io->stream == SND_PCM_STREAM_PLAYBACK)
-        pa_stream_connect_playback(pcm->stream, pcm->device, &pcm->buffer_attr, 0, NULL);
+        pa_stream_connect_playback(pcm->stream, pcm->device, &pcm->buffer_attr, 0, NULL, NULL);
     else
         pa_stream_connect_record(pcm->stream, pcm->device, &pcm->buffer_attr, 0);
 
Index: polyp/polyp.c
===================================================================
RCS file: /cvsroot/alsa/alsa-plugins/polyp/polyp.c,v
retrieving revision 1.1
diff -u -r1.1 polyp.c
--- polyp/polyp.c	21 Feb 2006 16:14:00 -0000	1.1
+++ polyp/polyp.c	22 Feb 2006 09:44:47 -0000
@@ -234,7 +234,7 @@
 
     assert(p && p->context && p->mainloop && (p->state == POLYP_STATE_INIT));
 
-    err = pa_context_connect(p->context, server, 1, NULL);
+    err = pa_context_connect(p->context, server, 0, NULL);
     if (err < 0)
         goto error;
 

Re: [RFC][PATCH] Transparent network support through polypaudio

[Takashi Iwai]

At Wed, 22 Feb 2006 10:48:36 +0100,
Pierre Ossman wrote:
> 
> Takashi Iwai wrote:
> > At Tue, 21 Feb 2006 17:38:37 +0100,
> > Pierre Ossman wrote:
> >>
> >> In case you missed it, I also opened a bug for the issue (I wasn't sure 
> >> how your work flow is so I tried all venues ;)). The bug also contains 
> >> an update not posted on the list:
> >>
> >> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1852
> >>
> >> I can generate a diff for you once the anon CVS is updated.
> > 
> > Yes, that'll be helpful.
> > 
> > I have currently very little time to look at ALSA MLs and BTS, so
> > please add me to Cc at the next update.
> > 
> > 
> 
> It seems your BTS cannot add cc:s, so I'll send you the diff here.

That's fine.  I always prefer mails than BTS (especially patches).
Committed to CVS now.

Could you provide a brief instruction for polyp plugin, too?


Thanks.

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

Takashi Iwai wrote:
> At Wed, 22 Feb 2006 10:48:36 +0100,
> Pierre Ossman wrote:
>> It seems your BTS cannot add cc:s, so I'll send you the diff here.
> 
> That's fine.  I always prefer mails than BTS (especially patches).
> Committed to CVS now.
> 
> Could you provide a brief instruction for polyp plugin, too?
> 

Here is a final update to the plugin and the documentation. This release 
adds capture volume and mute switches. This should also be the last API 
change in polypaudio before the next release, so this plugin should be 
stable for now.

-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com

[-- Attachment #2: polyp-update.patch --]
[-- Type: text/x-patch, Size: 11675 bytes --]

Index: polyp/ctl_polyp.c
===================================================================
RCS file: /cvsroot/alsa/alsa-plugins/polyp/ctl_polyp.c,v
retrieving revision 1.1
diff -u -r1.1 ctl_polyp.c
--- polyp/ctl_polyp.c	21 Feb 2006 16:14:00 -0000	1.1
+++ polyp/ctl_polyp.c	23 Feb 2006 12:33:43 -0000
@@ -30,15 +30,23 @@
 
     snd_polyp_t *p;
 
-    char *device;
+    char *source;
+    char *sink;
 
-    pa_cvolume volume;
+    pa_cvolume sink_volume;
+    pa_cvolume source_volume;
+
+    int sink_muted;
+    int source_muted;
 
     int subscribed;
     int updated;
 } snd_ctl_polyp_t;
 
-#define MIXER_NAME "Master"
+#define SOURCE_VOL_NAME "Capture Volume"
+#define SOURCE_MUTE_NAME "Capture Switch"
+#define SINK_VOL_NAME "Master Playback Volume"
+#define SINK_MUTE_NAME "Master Playback Switch"
 
 static void sink_info_cb(pa_context *c, const pa_sink_info *i, int is_last, void *userdata)
 {
@@ -50,18 +58,52 @@
 
     assert(ctl && i);
 
-    if (ctl->volume.channels == i->volume.channels) {
-        for (chan = 0;chan < ctl->volume.channels;chan++)
-            if (i->volume.values[chan] != ctl->volume.values[chan])
+    if (ctl->sink_volume.channels == i->volume.channels) {
+        for (chan = 0;chan < ctl->sink_volume.channels;chan++)
+            if (i->volume.values[chan] != ctl->sink_volume.values[chan])
                 break;
 
-        if (chan == ctl->volume.channels)
+        if (chan == ctl->sink_volume.channels)
             return;
 
         ctl->updated = 1;
     }
 
-    memcpy(&ctl->volume, &i->volume, sizeof(pa_cvolume));
+    memcpy(&ctl->sink_volume, &i->volume, sizeof(pa_cvolume));
+
+    if (!!ctl->sink_muted != !!i->mute) {
+        ctl->sink_muted = i->mute;
+        ctl->updated = 1;
+    }
+}
+
+static void source_info_cb(pa_context *c, const pa_source_info *i, int is_last, void *userdata)
+{
+    snd_ctl_polyp_t *ctl = (snd_ctl_polyp_t*)userdata;
+    int chan;
+
+    if (is_last)
+        return;
+
+    assert(ctl && i);
+
+    if (ctl->source_volume.channels == i->volume.channels) {
+        for (chan = 0;chan < ctl->source_volume.channels;chan++)
+            if (i->volume.values[chan] != ctl->source_volume.values[chan])
+                break;
+
+        if (chan == ctl->source_volume.channels)
+            return;
+
+        ctl->updated = 1;
+    }
+
+    memcpy(&ctl->source_volume, &i->volume, sizeof(pa_cvolume));
+
+    if (!!ctl->source_muted != !!i->mute) {
+        ctl->source_muted = i->mute;
+        ctl->updated = 1;
+    }
 }
 
 static void event_cb(pa_context *c, pa_subscription_event_type_t t,
@@ -72,9 +114,13 @@
 
     assert(ctl && ctl->p && ctl->p->context);
 
-    o = pa_context_get_sink_info_by_name(ctl->p->context, ctl->device,
+    o = pa_context_get_sink_info_by_name(ctl->p->context, ctl->sink,
         sink_info_cb, ctl);
     pa_operation_unref(o);
+
+    o = pa_context_get_source_info_by_name(ctl->p->context, ctl->source,
+        source_info_cb, ctl);
+    pa_operation_unref(o);
 }
 
 static int polyp_update_volume(snd_ctl_polyp_t *ctl)
@@ -84,26 +130,36 @@
 
     assert(ctl && ctl->p && ctl->p->context);
 
-    o = pa_context_get_sink_info_by_name(ctl->p->context, ctl->device,
+    o = pa_context_get_sink_info_by_name(ctl->p->context, ctl->sink,
         sink_info_cb, ctl);
     err = polyp_wait_operation(ctl->p, o);
     pa_operation_unref(o);
     if (err < 0)
         return err;
 
+    o = pa_context_get_source_info_by_name(ctl->p->context, ctl->source,
+        source_info_cb, ctl);
+    err = polyp_wait_operation(ctl->p, o);
+    pa_operation_unref(o);
+    if (err < 0)
+        return err;
+
     return 0;
 }
 
 static int polyp_elem_count(snd_ctl_ext_t *ext)
 {
     snd_ctl_polyp_t *ctl = ext->private_data;
+    int count = 0;
 
     assert(ctl);
 
-    if (ctl->device)
-        return 1;
+    if (ctl->source)
+        count += 2;
+    if (ctl->sink)
+        count += 2;
 
-    return 0;
+    return count;
 }
 
 static int polyp_elem_list(snd_ctl_ext_t *ext, unsigned int offset,
@@ -114,7 +170,19 @@
     assert(ctl);
 
     snd_ctl_elem_id_set_interface(id, SND_CTL_ELEM_IFACE_MIXER);
-    snd_ctl_elem_id_set_name(id, MIXER_NAME);
+
+    if (ctl->source) {
+        if (offset == 0)
+            snd_ctl_elem_id_set_name(id, SOURCE_VOL_NAME);
+        else if (offset == 1)
+            snd_ctl_elem_id_set_name(id, SOURCE_MUTE_NAME);
+    } else
+        offset += 2;
+
+    if (offset == 2)
+        snd_ctl_elem_id_set_name(id, SINK_VOL_NAME);
+    else if (offset == 3)
+        snd_ctl_elem_id_set_name(id, SINK_MUTE_NAME);
 
     return 0;
 }
@@ -126,8 +194,14 @@
 
     name = snd_ctl_elem_id_get_name(id);
 
-    if (strcmp(name, MIXER_NAME) == 0)
+    if (strcmp(name, SOURCE_VOL_NAME) == 0)
         return 0;
+    if (strcmp(name, SOURCE_MUTE_NAME) == 0)
+        return 1;
+    if (strcmp(name, SINK_VOL_NAME) == 0)
+        return 2;
+    if (strcmp(name, SINK_MUTE_NAME) == 0)
+        return 3;
 
     return SND_CTL_EXT_KEY_NOT_FOUND;
 }
@@ -140,7 +214,7 @@
 
     assert(ctl && ctl->p);
 
-    if (key != 0)
+    if (key > 3)
         return -EINVAL;
 
     err = polyp_finish_poll(ctl->p);
@@ -155,9 +229,19 @@
     if (err < 0)
         return err;
 
-    *type = SND_CTL_ELEM_TYPE_INTEGER;
+    if (key & 1)
+        *type = SND_CTL_ELEM_TYPE_BOOLEAN;
+    else
+        *type = SND_CTL_ELEM_TYPE_INTEGER;
+
     *acc = SND_CTL_EXT_ACCESS_READWRITE;
-    *count = ctl->volume.channels;
+
+    if (key == 0)
+        *count = ctl->source_volume.channels;
+    else if (key == 2)
+        *count = ctl->sink_volume.channels;
+    else
+        *count = 1;
 
     return 0;
 }
@@ -165,9 +249,6 @@
 static int polyp_get_integer_info(snd_ctl_ext_t *ext, snd_ctl_ext_key_t key,
     long *imin, long *imax, long *istep)
 {
-    if (key != 0)
-        return -EINVAL;
-
     *istep = 1;
     *imin = 0;
     *imax = PA_VOLUME_NORM;
@@ -180,12 +261,10 @@
 {
     snd_ctl_polyp_t *ctl = ext->private_data;
     int err, i;
+    pa_cvolume *vol = NULL;
 
     assert(ctl && ctl->p);
 
-    if (key != 0)
-        return -EINVAL;
-
     err = polyp_finish_poll(ctl->p);
     if (err < 0)
         return err;
@@ -198,8 +277,27 @@
     if (err < 0)
         return err;
 
-    for (i = 0;i < ctl->volume.channels;i++)
-        value[i] = ctl->volume.values[i];
+    switch (key) {
+    case 0:
+        vol = &ctl->source_volume;
+        break;
+    case 1:
+        *value = !ctl->source_muted;
+        break;
+    case 2:
+        vol = &ctl->sink_volume;
+        break;
+    case 3:
+        *value = !ctl->sink_muted;
+        break;
+    default:
+        return -EINVAL;
+    }
+
+    if (vol) {
+        for (i = 0;i < vol->channels;i++)
+            value[i] = vol->values[i];
+    }
 
     return 0;
 }
@@ -209,14 +307,11 @@
 {
     snd_ctl_polyp_t *ctl = ext->private_data;
     int err, i;
-    pa_cvolume vol;
     pa_operation *o;
+    pa_cvolume *vol = NULL;
 
     assert(ctl && ctl->p && ctl->p->context);
 
-    if (key != 0)
-        return -EINVAL;
-
     err = polyp_finish_poll(ctl->p);
     if (err < 0)
         return err;
@@ -229,21 +324,52 @@
     if (err < 0)
         return err;
 
-    for (i = 0;i < ctl->volume.channels;i++)
-        if (value[i] != ctl->volume.values[i])
-            break;
+    switch (key) {
+    case 0:
+        vol = &ctl->source_volume;
+        break;
+    case 1:
+        if (!!ctl->source_muted == !*value)
+            return 0;
+        ctl->source_muted = !*value;
+        break;
+    case 2:
+        vol = &ctl->sink_volume;
+        break;
+    case 3:
+        if (!!ctl->sink_muted == !*value)
+            return 0;
+        ctl->sink_muted = !*value;
+        break;
+    default:
+        return -EINVAL;
+    }
 
-    if (i == ctl->volume.channels)
-        return 0;
+    if (vol) {
+        for (i = 0;i < vol->channels;i++)
+            if (value[i] != vol->values[i])
+                break;
 
-    memset(&vol, 0, sizeof(pa_cvolume));
+        if (i == vol->channels)
+            return 0;
 
-    vol.channels = ctl->volume.channels;
-    for (i = 0;i < vol.channels;i++)
-        vol.values[i] = value[i];
+        for (i = 0;i < vol->channels;i++)
+            vol->values[i] = value[i];
 
-    o = pa_context_set_sink_volume_by_name(ctl->p->context, ctl->device, &vol,
-        NULL, NULL);
+        if (key == 0)
+            o = pa_context_set_source_volume_by_name(ctl->p->context,
+                ctl->source, vol, NULL, NULL);
+        else
+            o = pa_context_set_sink_volume_by_name(ctl->p->context,
+                ctl->sink, vol, NULL, NULL);
+    } else {
+        if (key == 1)
+            o = pa_context_set_source_mute_by_name(ctl->p->context,
+                ctl->source, ctl->source_muted, NULL, NULL);
+        else
+            o = pa_context_set_sink_mute_by_name(ctl->p->context,
+                ctl->sink, ctl->sink_muted, NULL, NULL);
+    }
 
     err = polyp_wait_operation(ctl->p, o);
     pa_operation_unref(o);
@@ -325,8 +451,10 @@
     if (ctl->p)
         polyp_free(ctl->p);
 
-    if (ctl->device)
-        free(ctl->device);
+    if (ctl->source)
+        free(ctl->source);
+    if (ctl->sink)
+        free(ctl->sink);
 
 	free(ctl);
 }
@@ -351,9 +479,12 @@
 {
     snd_ctl_polyp_t *ctl = (snd_ctl_polyp_t*)userdata;
 
-    assert(ctl && i && i->default_sink_name);
+    assert(ctl && i);
 
-    ctl->device = strdup(i->default_sink_name);
+    if (i->default_source_name && !ctl->source)
+        ctl->source = strdup(i->default_source_name);
+    if (i->default_sink_name && !ctl->sink)
+        ctl->sink = strdup(i->default_sink_name);
 }
 
 SND_CTL_PLUGIN_DEFINE_FUNC(polyp)
@@ -361,6 +492,8 @@
 	snd_config_iterator_t i, next;
 	const char *server = NULL;
 	const char *device = NULL;
+	const char *source = NULL;
+	const char *sink = NULL;
 	int err;
 	snd_ctl_polyp_t *ctl;
     pa_operation *o;
@@ -386,6 +519,20 @@
             }
             continue;
         }
+        if (strcmp(id, "source") == 0) {
+            if (snd_config_get_string(n, &source) < 0) {
+                SNDERR("Invalid type for %s", id);
+                return -EINVAL;
+            }
+            continue;
+        }
+        if (strcmp(id, "sink") == 0) {
+            if (snd_config_get_string(n, &sink) < 0) {
+                SNDERR("Invalid type for %s", id);
+                return -EINVAL;
+            }
+            continue;
+        }
 		SNDERR("Unknown field %s", id);
 		return -EINVAL;
 	}
@@ -403,9 +550,17 @@
     if (err < 0)
         goto error;
 
-    if (device)
-        ctl->device = strdup(device);
-    else {
+    if (source)
+        ctl->source = strdup(source);
+    else if (device)
+        ctl->source = strdup(device);
+
+    if (sink)
+        ctl->sink = strdup(sink);
+    else if (device)
+        ctl->sink = strdup(device);
+
+    if (!ctl->source || !ctl->sink) {
         o = pa_context_get_server_info(ctl->p->context, server_info_cb, ctl);
         err = polyp_wait_operation(ctl->p, o);
         pa_operation_unref(o);
@@ -415,7 +570,8 @@
 
     pa_context_set_subscribe_callback(ctl->p->context, event_cb, ctl);
 
-    o = pa_context_subscribe(ctl->p->context, PA_SUBSCRIPTION_MASK_SINK, NULL, NULL);
+    o = pa_context_subscribe(ctl->p->context,
+        PA_SUBSCRIPTION_MASK_SINK | PA_SUBSCRIPTION_MASK_SOURCE, NULL, NULL);
     err = polyp_wait_operation(ctl->p, o);
     pa_operation_unref(o);
     if (err < 0)
@@ -441,8 +597,10 @@
     return 0;
 
 error:
-    if (ctl->device)
-        free(ctl->device);
+    if (ctl->source)
+        free(ctl->source);
+    if (ctl->sink)
+        free(ctl->sink);
 
     if (ctl->p)
         polyp_free(ctl->p);

[-- Attachment #3: README-polyp --]
[-- Type: text/plain, Size: 1427 bytes --]

Polypaudio <--> ALSA plugins
============================

This plugin allows any program that uses the ALSA API to access a Polypaudio
sound daemon. In other words, native ALSA applications can play and record
sound across a network.

There are two plugins in the suite, one for PCM and one for mixer control. A
typical configuration will look like:

    pcm.polyp {
        type polyp
    }

    ctl.polyp {
        type polyp
    }

Put the above in ~/.asoundrc, or /etc/asound.conf, and use "polyp" as device
in your ALSA applications. For example:

    % aplay -Dpolyp foo.wav
    % amixer -Dpolyp

Polypaudio will accept more or less any format you throw at it. So a plug
wrapper is unnecessary. Mixing is also handled so dmix will only cause a
performance hit without any gain.

The plugins will respect your Polypaudio environment variables (like
POLYP_SERVER), but you can override these in ALSA's configuration files.

Both plugins accept the "server" parameter, specifying which Polypaudio server
to contact. Both also accept the "device" parameter, which indicate which
source and sink to use.

The mixer control plugin also accepts the parameters "source" and "sink" for
when you need to specify a sink/source combination with different names. If
you need to do this with PCM:s then specify two PCM:s with different "device".

If you do not specify any source and/or sink, then the server's defaults will
be used.

Re: [RFC][PATCH] Transparent network support through polypaudio

[Takashi Iwai]

At Thu, 23 Feb 2006 14:02:21 +0100,
Pierre Ossman wrote:
> 
> Takashi Iwai wrote:
> > At Wed, 22 Feb 2006 10:48:36 +0100,
> > Pierre Ossman wrote:
> >> It seems your BTS cannot add cc:s, so I'll send you the diff here.
> > 
> > That's fine.  I always prefer mails than BTS (especially patches).
> > Committed to CVS now.
> > 
> > Could you provide a brief instruction for polyp plugin, too?
> > 
> 
> Here is a final update to the plugin and the documentation. This release 
> adds capture volume and mute switches. This should also be the last API 
> change in polypaudio before the next release, so this plugin should be 
> stable for now.

Applied to CVS.  Thanks!


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

Takashi Iwai wrote:
> At Thu, 23 Feb 2006 14:02:21 +0100,
> Pierre Ossman wrote:
>> Here is a final update to the plugin and the documentation. This release 
>> adds capture volume and mute switches. This should also be the last API 
>> change in polypaudio before the next release, so this plugin should be 
>> stable for now.
> 
> Applied to CVS.  Thanks!
> 

On a related note, do you know if you guys have any plans on including 
alsa-plugins in SLES? Or NLD? We're rather keen on getting this included 
in most dists. :)

Rgds
-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Takashi Iwai]

At Fri, 24 Feb 2006 14:22:55 +0100,
Pierre Ossman wrote:
> 
> Takashi Iwai wrote:
> > At Thu, 23 Feb 2006 14:02:21 +0100,
> > Pierre Ossman wrote:
> >> Here is a final update to the plugin and the documentation. This release 
> >> adds capture volume and mute switches. This should also be the last API 
> >> change in polypaudio before the next release, so this plugin should be 
> >> stable for now.
> > 
> > Applied to CVS.  Thanks!
> > 
> 
> On a related note, do you know if you guys have any plans on including 
> alsa-plugins in SLES? Or NLD? We're rather keen on getting this included 
> in most dists. :)

Unfortuantely, it's already too late for SLES and NLD...


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

Takashi Iwai wrote:
> At Fri, 24 Feb 2006 14:22:55 +0100,
> Pierre Ossman wrote:
>> On a related note, do you know if you guys have any plans on including 
>> alsa-plugins in SLES? Or NLD? We're rather keen on getting this included 
>> in most dists. :)
> 
> Unfortuantely, it's already too late for SLES and NLD...
> 

Fair enough. But if we peer into the glass ball and look at the releases 
after that? :)

So far Debian, Mandriva and Suse (plain) seem to be the major dists that 
package alsa-plugins. Not bad, but having it in RHEL and SLES would make 
sure that the upper segment is covered as well.

-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

Just one more. :)

Seems I fumbled the control event code a bit. Only one event at a time 
got through. Here is a fix so that all four elements can change in one go.

-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com

[-- Attachment #2: polyp-update.patch --]
[-- Type: text/x-patch, Size: 3926 bytes --]

? polyp-update.patch
Index: polyp/ctl_polyp.c
===================================================================
RCS file: /cvsroot/alsa/alsa-plugins/polyp/ctl_polyp.c,v
retrieving revision 1.2
diff -u -r1.2 ctl_polyp.c
--- polyp/ctl_polyp.c	23 Feb 2006 14:31:13 -0000	1.2
+++ polyp/ctl_polyp.c	26 Feb 2006 21:48:32 -0000
@@ -48,6 +48,11 @@
 #define SINK_VOL_NAME "Master Playback Volume"
 #define SINK_MUTE_NAME "Master Playback Switch"
 
+#define UPDATE_SINK_VOL     0x01
+#define UPDATE_SINK_MUTE    0x02
+#define UPDATE_SOURCE_VOL   0x04
+#define UPDATE_SOURCE_MUTE  0x08
+
 static void sink_info_cb(pa_context *c, const pa_sink_info *i, int is_last, void *userdata)
 {
     snd_ctl_polyp_t *ctl = (snd_ctl_polyp_t*)userdata;
@@ -58,6 +63,11 @@
 
     assert(ctl && i);
 
+    if (!!ctl->sink_muted != !!i->mute) {
+        ctl->sink_muted = i->mute;
+        ctl->updated |= UPDATE_SINK_MUTE;
+    }
+
     if (ctl->sink_volume.channels == i->volume.channels) {
         for (chan = 0;chan < ctl->sink_volume.channels;chan++)
             if (i->volume.values[chan] != ctl->sink_volume.values[chan])
@@ -66,15 +76,10 @@
         if (chan == ctl->sink_volume.channels)
             return;
 
-        ctl->updated = 1;
+        ctl->updated |= UPDATE_SINK_VOL;
     }
 
     memcpy(&ctl->sink_volume, &i->volume, sizeof(pa_cvolume));
-
-    if (!!ctl->sink_muted != !!i->mute) {
-        ctl->sink_muted = i->mute;
-        ctl->updated = 1;
-    }
 }
 
 static void source_info_cb(pa_context *c, const pa_source_info *i, int is_last, void *userdata)
@@ -87,6 +92,11 @@
 
     assert(ctl && i);
 
+    if (!!ctl->source_muted != !!i->mute) {
+        ctl->source_muted = i->mute;
+        ctl->updated |= UPDATE_SOURCE_MUTE;
+    }
+
     if (ctl->source_volume.channels == i->volume.channels) {
         for (chan = 0;chan < ctl->source_volume.channels;chan++)
             if (i->volume.values[chan] != ctl->source_volume.values[chan])
@@ -95,15 +105,10 @@
         if (chan == ctl->source_volume.channels)
             return;
 
-        ctl->updated = 1;
+        ctl->updated |= UPDATE_SOURCE_VOL;
     }
 
     memcpy(&ctl->source_volume, &i->volume, sizeof(pa_cvolume));
-
-    if (!!ctl->source_muted != !!i->mute) {
-        ctl->source_muted = i->mute;
-        ctl->updated = 1;
-    }
 }
 
 static void event_cb(pa_context *c, pa_subscription_event_type_t t,
@@ -392,15 +397,33 @@
     unsigned int *event_mask)
 {
     snd_ctl_polyp_t *ctl = ext->private_data;
+    int offset;
 
     assert(ctl);
 
     if (!ctl->updated || !ctl->subscribed)
         return -EAGAIN;
 
-    polyp_elem_list(ext, 0, id);
+    if (ctl->source)
+        offset = 2;
+    else
+        offset = 0;
+
+    if (ctl->updated & UPDATE_SOURCE_VOL) {
+        polyp_elem_list(ext, 0, id);
+        ctl->updated &= ~UPDATE_SOURCE_VOL;
+    } else if (ctl->updated & UPDATE_SOURCE_MUTE) {
+        polyp_elem_list(ext, 1, id);
+        ctl->updated &= ~UPDATE_SOURCE_MUTE;
+    } else if (ctl->updated & UPDATE_SINK_VOL) {
+        polyp_elem_list(ext, offset + 0, id);
+        ctl->updated &= ~UPDATE_SINK_VOL;
+    } else if (ctl->updated & UPDATE_SINK_MUTE) {
+        polyp_elem_list(ext, offset + 1, id);
+        ctl->updated &= ~UPDATE_SINK_MUTE;
+    }
+
     *event_mask = SND_CTL_EVENT_MASK_VALUE;
-    ctl->updated = 0;
 
     return 1;
 }
@@ -416,11 +439,20 @@
 
 static int polyp_ctl_poll_descriptors(snd_ctl_ext_t *ext, struct pollfd *pfd, unsigned int space)
 {
+    int num;
+
 	snd_ctl_polyp_t *ctl = ext->private_data;
 
     assert(ctl && ctl->p);
 
-    return polyp_poll_descriptors(ctl->p, pfd, space);
+    num = polyp_poll_descriptors(ctl->p, pfd, space);
+    if (num < 0)
+        return num;
+
+    if (ctl->updated)
+        pa_mainloop_wakeup(ctl->p->mainloop);
+
+    return num;
 }
 
 static int polyp_ctl_poll_revents(snd_ctl_ext_t *ext, struct pollfd *pfd, unsigned int nfds, unsigned short *revents)

Re: [RFC][PATCH] Transparent network support through polypaudio

[Takashi Iwai]

At Mon, 27 Feb 2006 09:09:20 +0100,
Pierre Ossman wrote:
> 
> Just one more. :)
> 
> Seems I fumbled the control event code a bit. Only one event at a time 
> got through. Here is a fix so that all four elements can change in one go.

Applied to CVS now.
Could you provide a short changelog and a signed-off-by line for CVS
commit at next time, too?


Thanks,

Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

Takashi Iwai wrote:
> 
> Applied to CVS now.
> Could you provide a short changelog and a signed-off-by line for CVS
> commit at next time, too?
> 

Will do.

-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Lee Revell]

On Tue, 2006-02-14 at 10:47 +0100, Clemens Ladisch wrote:
> And you're speaking with mplayer's ALSA driver maintainer.
> Is there anything wrong with mplayer?  ;-) 

Actually, since you mention it...

I still get smoother playback with OSS emulation than mplayer's ALSA
driver.  I think it's because the ALSA driver resets the stream on
xruns:

alsa-space: xrun of at least 862.101 msecs. resetting stream3% 7 0                                    
alsa-space: xrun of at least 53.590 msecs. resetting stream.2% 27 0                                   
alsa-play: xrun of at least 5.844 msecs. resetting stream 5.1% 102 0                                  
alsa-space: xrun of at least 442.926 msecs. resetting stream1% 168 0                                  
alsa-space: xrun of at least 50.325 msecs. resetting stream 5.2% 4 0                                  
alsa-play: xrun of at least 15.953 msecs. resetting stream  5.1% 84 0        

This seems like a waste of CPU - after all there's nothing we can do but
drop frames if I'm trying to play a movie that my CPU can't quite
handle.  Shouldn't mplayer just ignore xruns?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Clemens Ladisch]

Lee Revell wrote:
> I still get smoother playback with OSS emulation than mplayer's ALSA
> driver.  I think it's because the ALSA driver resets the stream on
> xruns:
> 
> alsa-space: xrun of at least 862.101 msecs. resetting stream3% 7 0                                    
> 
> This seems like a waste of CPU - after all there's nothing we can do but
> drop frames if I'm trying to play a movie that my CPU can't quite
> handle.  Shouldn't mplayer just ignore xruns?

Yes, it should.  And it does in the CVS version; the last is horribly
outdated.


Regards,
Clemens


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Lee Revell]

On Wed, 2006-03-01 at 09:32 +0100, Clemens Ladisch wrote:
> Lee Revell wrote:
> > I still get smoother playback with OSS emulation than mplayer's ALSA
> > driver.  I think it's because the ALSA driver resets the stream on
> > xruns:
> > 
> > alsa-space: xrun of at least 862.101 msecs. resetting stream3% 7 0                                    
> > 
> > This seems like a waste of CPU - after all there's nothing we can do but
> > drop frames if I'm trying to play a movie that my CPU can't quite
> > handle.  Shouldn't mplayer just ignore xruns?
> 
> Yes, it should.  And it does in the CVS version; the last is horribly
> outdated.

Thanks for taking this on!  Mplayer's ALSA support was so bad for so
long, I had given up...

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [RFC][PATCH] Transparent network support through polypaudio

[Pierre Ossman]

Clemens Ladisch wrote:
> 
> And you're speaking with mplayer's ALSA driver maintainer.
> Is there anything wrong with mplayer?  ;-)
> 

I can now answer yes to this! :)

This little snippet causes me grief:

     if ((err = snd_card_next(&cards)) < 0 || cards < 0)
     {
       mp_msg(MSGT_AO,MSGL_ERR,"alsa-init: no soundcards found: %s\n", 
snd_strerror(err));
       return(0);
     }

mplayer does not require an actual, physical sound card (which is what 
this detects), so please don't check for one.

Rgds
-- 
Pierre Ossman                Telephone: +46-13-21 46 00
Cendio AB                    Web: http://www.cendio.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642