Re: [pulseaudio-discuss] pulse client implementation
On Wed, 26 Mar 2014 19:22:50 +, Pete Beardmore wrote: > specifically, the scenario whereby a user has explicitly configured > the app (via config file - read on initialisation) to use 'sinkX', and > then at some point during their 'session' (by which i mean 'time up > until the binary is killed'), has moved the app's current stream to an > alternative sink, 'sinkY'. finally, playback is stopped and restarted > > the question is, which sink should be used for the new playback stream? Well... the sink that the user expects to be used should be used. > the two takes on this were: > 1. the user explicitly specified 'sinkX' in the configuration, so > that's where it should play next > 2. the user explicitly moved the playback to 'sinkY', so that's where > it should play next Both approaches have their logic. Neither will satisfy every user. As Tanu says, it might be yet better to not have a persistent device settings for PulseAudio within the application at all. That's the path I took with "my" application (VLC media player). In addition, if the user selects a specific sink in the UI while there is no audio stream, we retain until the next audio stream starts or the application exits. This is not perfect: 1) We do not know what sink to hilight in the list of sinks when there is no audio stream - unless the user explicitly selected one sink via the GUI. 2) If the user selects a sink in the GUI, then exits the application without starting an audio stream, we forget the user setting completely. -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 1/2] direction: Add a couple of direction helper functions
On Thu, 2014-03-27 at 05:14 +0100, David Henningsson wrote:
> On 03/26/2014 10:52 AM, Tanu Kaskinen wrote:
> > ---
> > doxygen/doxygen.conf.in | 1 +
> > src/Makefile.am | 2 ++
> > src/map-file| 2 ++
> > src/pulse/direction.c | 46 ++
> > src/pulse/direction.h | 37 +
> > src/pulse/pulseaudio.h | 5 +++--
> > 6 files changed, 91 insertions(+), 2 deletions(-)
> > create mode 100644 src/pulse/direction.c
> > create mode 100644 src/pulse/direction.h
> >
> > diff --git a/doxygen/doxygen.conf.in b/doxygen/doxygen.conf.in
> > index fc6850d..43380e9 100644
> > --- a/doxygen/doxygen.conf.in
> > +++ b/doxygen/doxygen.conf.in
> > @@ -671,6 +671,7 @@ WARN_LOGFILE =
> > INPUT = @srcdir@/../src/pulse/channelmap.h \
> > @srcdir@/../src/pulse/context.h \
> > @srcdir@/../src/pulse/def.h \
> > + @srcdir@/../src/pulse/direction.h \
> > @srcdir@/../src/pulse/error.h \
> > @srcdir@/../src/pulse/ext-stream-restore.h \
> > @srcdir@/../src/pulse/ext-device-manager.h \
> > diff --git a/src/Makefile.am b/src/Makefile.am
> > index 99d76ce..5c2d5bc 100644
> > --- a/src/Makefile.am
> > +++ b/src/Makefile.am
> > @@ -746,6 +746,7 @@ pulseinclude_HEADERS = \
> > pulse/channelmap.h \
> > pulse/context.h \
> > pulse/def.h \
> > + pulse/direction.h \
> > pulse/error.h \
> > pulse/ext-device-manager.h \
> > pulse/ext-device-restore.h \
> > @@ -791,6 +792,7 @@ libpulse_la_SOURCES = \
> > pulse/channelmap.c pulse/channelmap.h \
> > pulse/context.c pulse/context.h \
> > pulse/def.h \
> > + pulse/direction.c pulse/direction.h \
> > pulse/error.c pulse/error.h \
> > pulse/ext-device-manager.c pulse/ext-device-manager.h \
> > pulse/ext-device-restore.c pulse/ext-device-restore.h \
> > diff --git a/src/map-file b/src/map-file
> > index fbad1a4..dc36fdc 100644
> > --- a/src/map-file
> > +++ b/src/map-file
> > @@ -146,6 +146,8 @@ pa_cvolume_set_position;
> > pa_cvolume_snprint;
> > pa_cvolume_snprint_verbose;
> > pa_cvolume_valid;
> > +pa_direction_to_string;
> > +pa_direction_valid;
> > pa_encoding_to_string;
> > pa_ext_device_manager_delete;
> > pa_ext_device_manager_enable_role_device_priority_routing;
> > diff --git a/src/pulse/direction.c b/src/pulse/direction.c
> > new file mode 100644
> > index 000..95f5e00
> > --- /dev/null
> > +++ b/src/pulse/direction.c
> > @@ -0,0 +1,46 @@
> > +/***
> > + This file is part of PulseAudio.
> > +
> > + Copyright 2014 Intel Corporation
> > +
> > + PulseAudio is free software; you can redistribute it and/or modify
> > + it under the terms of the GNU Lesser General Public License as published
> > + by the Free Software Foundation; either version 2.1 of the License,
> > + or (at your option) any later version.
> > +
> > + PulseAudio is distributed in the hope that it will be useful, but
> > + WITHOUT ANY WARRANTY; without even the implied warranty of
> > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + General Public License for more details.
> > +
> > + You should have received a copy of the GNU Lesser General Public License
> > + along with PulseAudio; if not, write to the Free Software
> > + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> > + USA.
> > +***/
> > +
> > +#include "direction.h"
> > +
> > +#include
> > +
> > +int pa_direction_valid(pa_direction_t direction) {
> > +if (direction != PA_DIRECTION_INPUT
> > +&& direction != PA_DIRECTION_OUTPUT
> > +&& direction != (PA_DIRECTION_INPUT | PA_DIRECTION_OUTPUT))
> > +return 0;
> > +
> > +return 1;
> > +}
> > +
> > +const char *pa_direction_to_string(pa_direction_t direction) {
> > +pa_init_i18n();
>
> Are pa_init_i18n and _() both declared with PA_GCC_PURE (or equivalent)?
> No side effects?
No they aren't, good catch. I probably added PA_GCC_PURE without
remembering that the function calls the i18n functions. I'll remove the
attribute.
> Both acked otherwise. I would probably not have started a separate file
> just for two functions, but it does not matter much.
I tried to find a place for them in the existing files, but pulse/util.h
was the best candidate, and the direction functions felt somehow out of
place there.
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] pulse client implementation
On Wed, 2014-03-26 at 19:22 +, Pete Beardmore wrote: > hi, > > i recently submitted a patch to an audio application which fixed what > i saw as a failure to DTRT wrt its pulse implementation > > specifically, the scenario whereby a user has explicitly configured > the app (via config file - read on initialisation) to use 'sinkX', and > then at some point during their 'session' (by which i mean 'time up > until the binary is killed'), has moved the app's current stream to an > alternative sink, 'sinkY'. finally, playback is stopped and restarted > > the question is, which sink should be used for the new playback stream? > > the two takes on this were: > 1. the user explicitly specified 'sinkX' in the configuration, so > that's where it should play next > 2. the user explicitly moved the playback to 'sinkY', so that's where > it should play next > > another way of looking at this scenario is: 'if the user takes control > of the app's stream (by moving it), should the app fall back to the > default (passing NULL on connection) and let the pulse server control > stream/sink placement, or should the app honour where the > configuration file originally places it? > > the disagreement was such, that it was suggested the only way forward > would be to ask the pulse devs for their opinions. i appreciate this > isn't a pulseaudio problem, so thanks for any input My recommendation would be to get rid of the setting in the configuration file. Let pulseaudio take care of the routing. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Added module-ofono-switch-on-voicecall
On Wed, 2014-03-26 at 09:17 -0700, Felipe Tonello wrote: > > I think the UCM code in PulseAudio should somehow automatically detect > > that this device is a dummy device that actually just controls the DSP > > routing. Could you share the UCM configuration and "pactl list cards" > > output so I have a better idea of the setup? I can't give concrete > > suggestions about how to implement the auto-detection without > > understanding the setup better. > > I don't have access to it right now. But why would this be useful > anyway? How do you suggest us to implement this in UCM, since UCM > library doesn't have any option for that? Maybe add a PA specific > option? Yes, some kind of addition to UCM would likely be needed. I don't like the idea of having PulseAudio specific stuff in UCM, I think we should first propose a generic solution, and only if the alsa develpers are against that for some strange reason, then we can add a PulseAudio specific hack to UCM. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
