Re: [NEW] audio/alsa-lib-1.2.8
Hi,
Here is newer version,
- include files are at /usr/local/include/alsa-lib/{alsa/...}
- libraries at /usr/local/lib/alsa-lib/...
- alsa.m4 is at /usr/local/share/aclocal
- pkg-config files are at /usr/local/lib/pkgconfig
but renamed to alsa -> alsa-lib, alsa-topology -> alsa-lib-topology
- configuration files at /usr/local/share/alsa-lib/alsa.conf (not /alsa/)
- /usr/local/bin/aserver not changed
Best regards,
--
SASANO Takayoshi (JG1UAA)
alsa-lib.tgz
Description: Binary data
Re: [NEW] audio/alsa-lib-1.2.8
Hi, > They do not, files would go in /usr/local/include/alsa-lib/alsa/xxx, > add -I/usr/local/include/alsa-lib to CPPFLAGS (or CFLAGS if the build > system doesn't cope with CPPFLAGS). > > Similar with LDFLAGS for libraries (and setting rpath may be needed > too). like inotify, /usr/local/include/alsa-lib/(alsa/xxx) and /usr/local/lib/alsa-lib/(xxx) ? -- SASANO Takayoshi (JG1UAA)
Re: [NEW] audio/alsa-lib-1.2.8
On 2023/01/15 10:22, SASANO Takayoshi wrote:
> Hi,
>
> > Let's keep it simple like:
> > /usr/local/lib/alsa-lib/...
> > /usr/local/include/alsa-lib/...
>
> Really? I thought:
>
> /usr/local/alsa-lib/include
> /usr/local/alsa-lib/lib
>
> (how about /usr/local/linux-alsa/{include,lib}?)
>
> Both are not difficult to write alsa-lib's Makefile
> but very hard to porting apps to /usr/local/lib/alsa-lib and
> /usr/local/include/alsa-lib.
>
> In alsa-utils, about 50 or more files are needed to be patched
> if header files are stored into /usr/local/include/alsa-lib .
They do not, files would go in /usr/local/include/alsa-lib/alsa/xxx,
add -I/usr/local/include/alsa-lib to CPPFLAGS (or CFLAGS if the build
system doesn't cope with CPPFLAGS).
Similar with LDFLAGS for libraries (and setting rpath may be needed
too).
Though porting to sndio is still *much* preferred.
Re: [NEW] audio/alsa-lib-1.2.8
On Sun, Jan 15, 2023 at 10:22:17AM +0900, SASANO Takayoshi wrote:
> Hi,
>
> > Let's keep it simple like:
> > /usr/local/lib/alsa-lib/...
> > /usr/local/include/alsa-lib/...
>
> Really? I thought:
>
> /usr/local/alsa-lib/include
> /usr/local/alsa-lib/lib
Sure this is fine as well :-)
> (how about /usr/local/linux-alsa/{include,lib}?)
>
> Both are not difficult to write alsa-lib's Makefile
> but very hard to porting apps to /usr/local/lib/alsa-lib and
> /usr/local/include/alsa-lib.
>
> In alsa-utils, about 50 or more files are needed to be patched
> if header files are stored into /usr/local/include/alsa-lib .
>
> I think this is too much, but simply do write a patch that
> it is still neccesary...
> --
> SASANO Takayoshi (JG1UAA)
>
--
Antoine
Re: [NEW] audio/alsa-lib-1.2.8
Hi,
> Let's keep it simple like:
> /usr/local/lib/alsa-lib/...
> /usr/local/include/alsa-lib/...
Really? I thought:
/usr/local/alsa-lib/include
/usr/local/alsa-lib/lib
(how about /usr/local/linux-alsa/{include,lib}?)
Both are not difficult to write alsa-lib's Makefile
but very hard to porting apps to /usr/local/lib/alsa-lib and
/usr/local/include/alsa-lib.
In alsa-utils, about 50 or more files are needed to be patched
if header files are stored into /usr/local/include/alsa-lib .
I think this is too much, but simply do write a patch that
it is still neccesary...
--
SASANO Takayoshi (JG1UAA)
Re: [NEW] audio/alsa-lib-1.2.8
On Sat, Jan 07, 2023 at 12:39:00PM +, Stuart Henderson wrote: > On 2023/01/07 13:25, Antoine Jacoutot wrote: > > On Sat, Jan 07, 2023 at 08:11:22PM +0900, SASANO Takayoshi wrote: > > > Hello, > > > > > > alsa-lib.tgz (take3) attached. > > > > > > > The most common method to deal with this in ports is to continue to > > > > use /usr/local but install under subdirectories with a non-standard > > > > prefix, often 'e'; for example libraries under /usr/local/lib/ealsa > > > > and headers under /usr/local/include/ealsa. > > > > > > Many code uses so putting include files to > > > /usr//include/ealsa is hard to use. > > > > > > I show my idea via attached archive, almost all alsa components are > > > installed into /usr/local/ealsa. > > > > I really find this weird. > > We only do this "e" stuff for things we have in base already (like openssl). > > For stuff that we want to keep "hidden" we usually just install in a > > subdir, > > like libinotify, heimdal etc. > > If you have a good idea that is unlikely to be picked up then yes. > I don't particularly want to look into 100-odd ports to find a "safe" > directory name for that though ;) Let's keep it simple like: /usr/local/lib/alsa-lib/... /usr/local/include/alsa-lib/... -- Antoine
Re: [NEW] audio/alsa-lib-1.2.8
Hi, aaauuuggghhh, here is the archive. sorry! On Sat, 07 Jan 2023 21:23:19 +0900, Stuart Henderson wrote: > > On 2023/01/07 20:11, SASANO Takayoshi wrote: > > Hello, > > > > alsa-lib.tgz (take3) attached. > > > > > The most common method to deal with this in ports is to continue to > > > use /usr/local but install under subdirectories with a non-standard > > > prefix, often 'e'; for example libraries under /usr/local/lib/ealsa > > > and headers under /usr/local/include/ealsa. > > > > Many code uses so putting include files to > > /usr//include/ealsa is hard to use. > > > I show my idea via attached archive, almost all alsa components are > > installed into /usr/local/ealsa. > > There's no attachment; there's no big problem though; install headers > to /usr/local/include/ealsa/alsa and add -I/usr/local/include/ealsa to > preprocessor flags when building against it. > > > pc file for pkg-config is renamed and installed into /usr/local/lib. > > > > - /usr/local/lib/pkgconfig/ealsa-topology.pc (alsa-topology.pc) > > - /usr/local/lib/pkgconfig/ealsa.pc (alsa.pc) > > > > m4 script for aclocal is kept original. > > > > - /usr/local/share/aclocal/alsa.m4 > > > > > > by the way, CONFIGURE_ARGS in Makefile looks ignored when CONFIGURE_STYLE > > is autoreconf. even if CONFIGURE_STYLE = --prefix=/usr/local/ealsa, > > config.log says "--prefix=/usr/local/ealsa --prefix=/usr/local", I saw. > > It's not ignored, but there's no way to override prefix like that in > ports infrastructure. > -- SASANO Takayoshi (JG1UAA) alsa-lib.tgz Description: Binary data
Re: [NEW] audio/alsa-lib-1.2.8
On 2023/01/07 13:25, Antoine Jacoutot wrote: > On Sat, Jan 07, 2023 at 08:11:22PM +0900, SASANO Takayoshi wrote: > > Hello, > > > > alsa-lib.tgz (take3) attached. > > > > > The most common method to deal with this in ports is to continue to > > > use /usr/local but install under subdirectories with a non-standard > > > prefix, often 'e'; for example libraries under /usr/local/lib/ealsa > > > and headers under /usr/local/include/ealsa. > > > > Many code uses so putting include files to > > /usr//include/ealsa is hard to use. > > > > I show my idea via attached archive, almost all alsa components are > > installed into /usr/local/ealsa. > > I really find this weird. > We only do this "e" stuff for things we have in base already (like openssl). > For stuff that we want to keep "hidden" we usually just install in a subdir, > like libinotify, heimdal etc. If you have a good idea that is unlikely to be picked up then yes. I don't particularly want to look into 100-odd ports to find a "safe" directory name for that though ;)
Re: [NEW] audio/alsa-lib-1.2.8
On Sat, Jan 07, 2023 at 08:11:22PM +0900, SASANO Takayoshi wrote: > Hello, > > alsa-lib.tgz (take3) attached. > > > The most common method to deal with this in ports is to continue to > > use /usr/local but install under subdirectories with a non-standard > > prefix, often 'e'; for example libraries under /usr/local/lib/ealsa > > and headers under /usr/local/include/ealsa. > > Many code uses so putting include files to > /usr//include/ealsa is hard to use. > > I show my idea via attached archive, almost all alsa components are > installed into /usr/local/ealsa. I really find this weird. We only do this "e" stuff for things we have in base already (like openssl). For stuff that we want to keep "hidden" we usually just install in a subdir, like libinotify, heimdal etc. -- Antoine
Re: [NEW] audio/alsa-lib-1.2.8
On 2023/01/07 20:11, SASANO Takayoshi wrote: > Hello, > > alsa-lib.tgz (take3) attached. > > > The most common method to deal with this in ports is to continue to > > use /usr/local but install under subdirectories with a non-standard > > prefix, often 'e'; for example libraries under /usr/local/lib/ealsa > > and headers under /usr/local/include/ealsa. > > Many code uses so putting include files to > /usr//include/ealsa is hard to use. > I show my idea via attached archive, almost all alsa components are > installed into /usr/local/ealsa. There's no attachment; there's no big problem though; install headers to /usr/local/include/ealsa/alsa and add -I/usr/local/include/ealsa to preprocessor flags when building against it. > pc file for pkg-config is renamed and installed into /usr/local/lib. > > - /usr/local/lib/pkgconfig/ealsa-topology.pc (alsa-topology.pc) > - /usr/local/lib/pkgconfig/ealsa.pc (alsa.pc) > > m4 script for aclocal is kept original. > > - /usr/local/share/aclocal/alsa.m4 > > > by the way, CONFIGURE_ARGS in Makefile looks ignored when CONFIGURE_STYLE > is autoreconf. even if CONFIGURE_STYLE = --prefix=/usr/local/ealsa, > config.log says "--prefix=/usr/local/ealsa --prefix=/usr/local", I saw. It's not ignored, but there's no way to override prefix like that in ports infrastructure.
Re: [NEW] audio/alsa-lib-1.2.8
Hello, > Having two audio layers with different semantics increases the > probability of subtle audio problems (stuttering, desynchronization, > etc.), which are very time-consuming to fix. Furthermore, > alsa-over-sndio is very unlikely to work in all > program/device/configuration combinations. alsa-plugins has ALSA->JACK and ALSA->PluseAudio plugin and they could compiled in my -current box. But JACK and PulseAudio on OpenBSD goes sndio sink, so I am afraid that there is something trouble for using alsa-plugins via these audio frameworks. Simply enable OSS plugin only, I think (because alsa is for test purpose). > I'd suggest adding a sndio backend. The API is designed to make this > process as simple as possible. Let us know if you want to try this > approach, I can help with the code. Porting applications to support sndio is the best solution. Indeed I added sndio backend for DireWolf software TNC, but many other ham radio software (for alsa) remains... -- SASANO Takayoshi (JG1UAA)
Re: [NEW] audio/alsa-lib-1.2.8
Hello, alsa-lib.tgz (take3) attached. > The most common method to deal with this in ports is to continue to > use /usr/local but install under subdirectories with a non-standard > prefix, often 'e'; for example libraries under /usr/local/lib/ealsa > and headers under /usr/local/include/ealsa. Many code uses so putting include files to /usr//include/ealsa is hard to use. I show my idea via attached archive, almost all alsa components are installed into /usr/local/ealsa. pc file for pkg-config is renamed and installed into /usr/local/lib. - /usr/local/lib/pkgconfig/ealsa-topology.pc (alsa-topology.pc) - /usr/local/lib/pkgconfig/ealsa.pc (alsa.pc) m4 script for aclocal is kept original. - /usr/local/share/aclocal/alsa.m4 by the way, CONFIGURE_ARGS in Makefile looks ignored when CONFIGURE_STYLE is autoreconf. even if CONFIGURE_STYLE = --prefix=/usr/local/ealsa, config.log says "--prefix=/usr/local/ealsa --prefix=/usr/local", I saw. patches/patch-configure_ac contains workaround, prefix="$prefix/ealsa". Regards, -- SASANO Takayoshi (JG1UAA)
Re: [NEW] audio/alsa-lib-1.2.8
On Thu, Jan 05, 2023 at 03:31:57PM +0900, SASANO Takayoshi wrote: > Hi, > > > Unless installed in a way to make it hard to pick up accidentally (e.g. > > a non-standard directory, which has its own problems) I expect the > > amount of work needed to cope with this in the rest of the ports tree > > is likely to be quite a lot more than that needed to port a couple of > > applications from alsa to sndio. > > That's important. OpenBSD's standard is sndio, not alsa. > I expected this alsa port to use temporary, for example; > > - until the application supports sndio > - rescue that cannot support sndio > > So alsa should not be first choice on OpenBSD. > Having two audio layers with different semantics increases the probability of subtle audio problems (stuttering, desynchronization, etc.), which are very time-consuming to fix. Furthermore, alsa-over-sndio is very unlikely to work in all program/device/configuration combinations. I'd suggest adding a sndio backend. The API is designed to make this process as simple as possible. Let us know if you want to try this approach, I can help with the code.
Re: [NEW] audio/alsa-lib-1.2.8
On 2023/01/05 15:31, SASANO Takayoshi wrote: > Hi, > > > Unless installed in a way to make it hard to pick up accidentally (e.g. > > a non-standard directory, which has its own problems) I expect the > > amount of work needed to cope with this in the rest of the ports tree > > is likely to be quite a lot more than that needed to port a couple of > > applications from alsa to sndio. > > That's important. OpenBSD's standard is sndio, not alsa. > I expected this alsa port to use temporary, for example; > > - until the application supports sndio > - rescue that cannot support sndio > > So alsa should not be first choice on OpenBSD. > > How about to use PERMIT_PACKAGE=No (and PERMIT_DISTFILES=No?) to > reduce install accidentaly, and install alsa suites into > /usr/local/alsa or somewhere? Assuming you're wanting to add a port/package for MSHV which would depend on alsa, PERMIT_PACKAGE=No doesn't help, the alsa packages will still be built and installed when required as a dependency on bulk build machines. A non-standard directory would help, but not one which is likely to appear in search paths - I would think some software might look under /usr/local/alsa. The most common method to deal with this in ports is to continue to use /usr/local but install under subdirectories with a non-standard prefix, often 'e'; for example libraries under /usr/local/lib/ealsa and headers under /usr/local/include/ealsa. pkg-config files need to stay under /usr/local/lib/pkgconfig but the filenames can have a prefix instead so the usual pkg-config checks won't find them unless they're patched.
Re: [NEW] audio/alsa-lib-1.2.8
Hi, > Unless installed in a way to make it hard to pick up accidentally (e.g. > a non-standard directory, which has its own problems) I expect the > amount of work needed to cope with this in the rest of the ports tree > is likely to be quite a lot more than that needed to port a couple of > applications from alsa to sndio. That's important. OpenBSD's standard is sndio, not alsa. I expected this alsa port to use temporary, for example; - until the application supports sndio - rescue that cannot support sndio So alsa should not be first choice on OpenBSD. How about to use PERMIT_PACKAGE=No (and PERMIT_DISTFILES=No?) to reduce install accidentaly, and install alsa suites into /usr/local/alsa or somewhere? -- SASANO Takayoshi (JG1UAA)
Re: [NEW] audio/alsa-lib-1.2.8
I'm worried that a lot of other ports will pick this up if installed. 'grep -wiR alsa' over build logs suggests it's in the order of a hundred ports - apart from the problem of missing deps, we don't want it taking priority over native sndio support in applications. Unless installed in a way to make it hard to pick up accidentally (e.g. a non-standard directory, which has its own problems) I expect the amount of work needed to cope with this in the rest of the ports tree is likely to be quite a lot more than that needed to port a couple of applications from alsa to sndio.
Re: [NEW] audio/alsa-lib-1.2.8
Hello, > SHARED_LIBS = asound 0.0 # 2.0 > SHARED_LIBS += atopology 0.0 # 2.0 I will fix them before commit. > with that fixed the port looks fine to me, and builds fine too. What > I don't know is how it's supposed to be used. Is it needed to port > something else? alsa-lib is just the beginning. I want to try MSHV (http://lz2hv.org/mshv) FT8 ham radio software on OpenBSD and this requires ALSA library (it is an idea that rewriting with sndio, but it looks difficult). And, alsa-utils and alsa-plugins are also needed to use alsa-lib. Currently I sent pull-requests for alsa-utils and alsa-plugins, but I think it takes long time to merge (indeed three months has passed for alsa-lib to merge). https://github.com/alsa-project/alsa-utils/pull/186 https://github.com/alsa-project/alsa-plugins/pull/48 Which is better, wait for ALSA team response or work our patch simultaneously? -- SASANO Takayoshi (JG1UAA)
Re: [NEW] audio/alsa-lib-1.2.8
On 2023/01/04 16:48:05 +0900, SASANO Takayoshi wrote: > Hello, > > - patch for configure.ac is simplified by your idea. > (new diff is also posted to github) thanks! > - warning of pcm.c is fixed, but I use (long)status->x.tv_sec cast > because of other printf() uses same thing. no %ld -> %lld format change. generally speaking I'm not sure this is fine. time_t is 64 bit long here. However, it matches what upstream already do (albeit should change) and seems to be used only for logging, so maybe it's fine. > - add comment before NO_TEST Ooops, sorry, yesterday I failed to notice that SHARED_LIBS should start at zero for new ports: SHARED_LIBS = asound 0.0 # 2.0 SHARED_LIBS += atopology 0.0 # 2.0 > ok? with that fixed the port looks fine to me, and builds fine too. What I don't know is how it's supposed to be used. Is it needed to port something else? Thanks, Omar Polo
Re: [NEW] audio/alsa-lib-1.2.8
Hello, - patch for configure.ac is simplified by your idea. (new diff is also posted to github) - warning of pcm.c is fixed, but I use (long)status->x.tv_sec cast because of other printf() uses same thing. no %ld -> %lld format change. - add comment before NO_TEST ok? -- SASANO Takayoshi (JG1UAA) alsa-lib.tgz Description: Binary data
Re: [NEW] audio/alsa-lib-1.2.8
On 2023/01/03 11:25:23 +0900, SASANO Takayoshi wrote: > Hi, > > previous ports cannot support alsa-plugin due to libdl detection, > here is new ports with patch. (the patch is sent same as pull-request at > https://github.com/alsa-project/alsa-lib/pull/290 ) looked for curiosity; the patch for configure.ac can be simplified a bit: Index: configure.ac --- configure.ac.orig +++ configure.ac @@ -255,9 +255,8 @@ AC_ARG_WITH(libdl, [ have_libdl="$withval" ], [ have_libdl="yes" ]) HAVE_LIBDL= if test "$have_libdl" = "yes"; then - AC_CHECK_LIB([dl], [dlsym], [HAVE_LIBDL="yes"]) + AC_SEARCH_LIBS([dlsym], [dl], [HAVE_LIBDL="yes"]) if test "$HAVE_LIBDL" = "yes" ; then -ALSA_DEPLIBS="$ALSA_DEPLIBS -ldl" AC_DEFINE([HAVE_LIBDL], 1, [Have libdl]) fi else AC_SEARCH_LIBS tries first to see if the functions are provided in libc and if not tries with the list of libraries provided (`dl' in this case.) It works equally well for linux and the BSDs. (on linux "-ldl" is automatically added to LIBS and handled by automake, and so ALSA_DEPLIBS is not needed at all.) (from a quick look upstream could switch also the other checks to AC_SEARCH_LIBS and drop ALSA_DEPLIBS entirely. the only place I'm not sure is when looking for clock_gettime in -lrt) I'd add a comment before NO_TESTS since there seem to be a regress suite, but does not compile. There are two places in src/pcm/pcm.c where it prints a time_t as it were `long': pcm.c:2357:6: warning: format specifies type 'long' but the argument has type 'time_t' (aka 'long long') [-Wformat] status->trigger_tstamp.tv_sec, ^ pcm.c:2360:3: warning: format specifies type 'long' but the argument has type 'time_t' (aka 'long long') [-Wformat] status->tstamp.tv_sec, status->tstamp.tv_nsec / 1000); ^ 2 warnings generated. could be patched to cast the time_t to `long long' and using the "%lld" format. No mean to test it. Is it required by other ports for compatibility? Port looks fine to me anyawy.
Re: [NEW] audio/alsa-lib-1.2.8
Hi, previous ports cannot support alsa-plugin due to libdl detection, here is new ports with patch. (the patch is sent same as pull-request at https://github.com/alsa-project/alsa-lib/pull/290 ) -- SASANO Takayoshi (JG1UAA) alsa-lib.tgz Description: Binary data
[NEW] audio/alsa-lib-1.2.8
Hello, to acclerate alsa-utils and alsa-plugin ports development, post alsa-lib ports first. (I sent pull-request of alsa-utils for *BSD; https://github.com/alsa-project/alsa-utils/pull/186 if there is no enough time for us, use same diff in ports until they are merged) -- SASANO Takayoshi (JG1UAA) alsa-lib.tgz Description: Binary data
