[pulseaudio-discuss] libpulsecore dependency on libpulsecommon

Brian Cameron brian.cameron at oracle.com
Wed Nov 16 06:24:29 PST 2011


Maarten:

1024*1024*16 or 16,777,216 (or 16M) is a very common number in
computer programs.  Why not just define and use something like
SIXTEEN_MB in a common header file instead of hardcoding 1024*1024*16
in different places where it needs to be kept in sync.  This should
not be so complicated.

I am guessing since this is hardcoded, that users are not expected to
configure or tune this part of the code much.

If it is not necessary for the #define to so closely associate with
"SCACHE", then it might just be simpler to use a more general
solution like this.  The need to keep things in sync probably should
just be documented somewhere, at least in comments for developers to
see.

Brian


On 11/16/11 05:49 AM, Maarten Bosmans wrote:
> I'm looking for some guidance on how to solve
> https://bugs.freedesktop.org/show_bug.cgi?id=41539.
> The problem is that pulsecore/pstream.c (in libpulsecommon) includes
> pulsecore/core-scache.h (which is itself in and includes from
> libpulsecore), this is wrong. Apparantly it causes real trouble on
> Solaris.
>
> The header core-scache.h is only included to make the
> PA_SCACHE_ENTRY_SIZE_MAX preprocessor symbol available.
> There are several solutions possible.
>   - Move the #define to a file in libpulsecommon. This is the solution
> proposed in the patch attached to the bug. However, I don't like the
> proposed new location in memchunk.h, because it is quite unrelated to
> scache functionality.
>   - Move the #define to pulse/scache.h. In this case we need to guard
> against the symbol being externally visible.
>   - Simply hardcode the value of 1024*1024*16 in pstream.c, perhaps
> with a comment that says it should stay in sink with
> PA_SCACHE_ENTRY_SIZE_MAX.
>
> Which solution is preferred?
>
> There are also other source-level dependenies from
> libpulse/libpulsecommon on files from libpulsecore.
> pulse/volume.c ->  pulsecore/sample-util.h
> pulse/channelmap.c ->  pulsecore/sample-util.h
> pulsecore/core-util.c ->  pulsecore/cpu-x86.h
>
> Is this also something we want to address? (I can make patches)
>
> Maarten
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss



More information about the pulseaudio-discuss mailing list