[PATCH] Add env vars for PA_ALSA_PATHS_DIR and PA_ALSA_PROFILE_SETS_DIR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2016-12-01 at 12:55 +0100, Albert Astals Cid wrote:
> commit 5621ce4ecc63c289a99ec09cddd8088fa65db726
> Author: Albert Astals Cid <albert.astals at canonical.com>
> Date:   Wed Nov 23 17:03:41 2016 +0100

"git am" doesn't recognize this formatting. Could you use "git send-
email" for submitting patches? Instructions are available here:
https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/

>     Add env var for data dir
>     
>     Helps making pulseaudio relocatable, i.e. having the code and data in a different
>     root path than the one that was decided on compilation time

I asked you to provide a use case in the commit message, but you only
added an explanation for what "relocatable" means. If want to make a
snap for PulseAudio and being relocatable helps with that, say it in
the commit message.

Also explain *why* you want to make a snap for PulseAudio, because I
don't really see a use case for that. AFAIK, the usual reason for
distributing applications as snaps is that snaps work on any
distribution and they run in a secure sandbox. However, the model
doesn't work well for system daemons. How are applications expected to
connect to the sandboxed PulseAudio? Do you export the socket from the
PulseAudio sandbox? If so, how do you avoid conflicts with the
operating system's own PulseAudio?

Another problem is that if you want to use udev, that's not portable,
because mixing different versions of libudev and udevd is not expected
to work.

By the way, is it common for snaps to bundle unaltered binary debs from
Ubuntu? A lot of software has files in /usr/share, and if snaps can't
install their files there, I'd expect a lot of debs to not be
relocatable.

> diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
> index 3dbf6b1..da5b657 100644
> --- a/src/modules/alsa/alsa-mixer.c
> +++ b/src/modules/alsa/alsa-mixer.c
> @@ -2507,8 +2507,17 @@ static int path_verify(pa_alsa_path *p) {
>  static const char *get_default_paths_dir(void) {
>      if (pa_run_from_build_tree())
>          return PA_SRCDIR "/modules/alsa/mixer/paths/";
> -    else
> -        return PA_ALSA_PATHS_DIR;
> +    else {
> +        static const char *paths_dir = NULL;
> +        if (!paths_dir) {
> +            paths_dir = getenv("PULSE_DATA_PATH");
> +            if (!paths_dir)
> +                paths_dir = PA_ALSA_PATHS_DIR;
> +            else
> +                paths_dir = pa_sprintf_malloc("%s/alsa-mixer/paths", paths_dir);

paths_dir is never freed. We try to keep PulseAudio Valgrind-clean, so
I think this should be handled in some other way. I think it would be
best to require the function caller to free the returned string.

Another solution that I'd be ok with would be to save the datadir in
pa_core when pulseaudio starts. I think the alsa-mixer code doesn't
currently always have a pointer to pa_core, but that's probably not
difficult to change.

> +        }
> +        return paths_dir;
> +    }
>  }
>  
>  pa_alsa_path* pa_alsa_path_new(const char *paths_dir, const char *fname, pa_alsa_direction_t direction) {
> @@ -4333,6 +4342,23 @@ void pa_alsa_decibel_fix_dump(pa_alsa_decibel_fix *db_fix) {
>      pa_xfree(db_values);
>  }
>  
> +static const char *alsa_profile_sets_dir() {
> +    if (pa_run_from_build_tree())
> +        return PA_SRCDIR "/modules/alsa/mixer/profile-sets/";
> +    else {
> +        static const char *profile_sets_dir = NULL;
> +        if (!profile_sets_dir) {
> +            profile_sets_dir = getenv("PULSE_DATA_PATH");
> +            if (!profile_sets_dir)
> +                profile_sets_dir = PA_ALSA_PROFILE_SETS_DIR;
> +            else
> +                profile_sets_dir = pa_sprintf_malloc("%s/alsa-mixer/profile-sets", profile_sets_dir);

Same comment as above.

-- 
Tanu

https://www.patreon.com/tanuk


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux