mpg123-devel Mailing List for mpg123
Brought to you by:
sobukus
You can subscribe to this list here.
2006 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
|
May
|
Jun
(6) |
Jul
(4) |
Aug
(17) |
Sep
(2) |
Oct
(13) |
Nov
|
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(2) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(7) |
Dec
(6) |
2008 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(18) |
May
(16) |
Jun
(10) |
Jul
(13) |
Aug
(14) |
Sep
(12) |
Oct
(32) |
Nov
(12) |
Dec
(33) |
2009 |
Jan
(2) |
Feb
(10) |
Mar
(16) |
Apr
(48) |
May
(92) |
Jun
(68) |
Jul
(37) |
Aug
(28) |
Sep
(61) |
Oct
(43) |
Nov
(33) |
Dec
(48) |
2010 |
Jan
(8) |
Feb
(27) |
Mar
(16) |
Apr
(11) |
May
(34) |
Jun
(27) |
Jul
(15) |
Aug
(16) |
Sep
(24) |
Oct
(14) |
Nov
(17) |
Dec
(9) |
2011 |
Jan
(21) |
Feb
(12) |
Mar
(8) |
Apr
(33) |
May
(2) |
Jun
(29) |
Jul
(16) |
Aug
(27) |
Sep
(27) |
Oct
(11) |
Nov
(16) |
Dec
(4) |
2012 |
Jan
(40) |
Feb
(12) |
Mar
(40) |
Apr
(34) |
May
(32) |
Jun
(6) |
Jul
(7) |
Aug
(13) |
Sep
(8) |
Oct
(12) |
Nov
(14) |
Dec
(5) |
2013 |
Jan
(3) |
Feb
(19) |
Mar
(2) |
Apr
(7) |
May
(30) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(23) |
Oct
(8) |
Nov
(3) |
Dec
(1) |
2014 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
(9) |
May
(8) |
Jun
(2) |
Jul
|
Aug
(15) |
Sep
(7) |
Oct
(1) |
Nov
(5) |
Dec
|
2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(13) |
Aug
(16) |
Sep
(26) |
Oct
(2) |
Nov
(5) |
Dec
|
2016 |
Jan
(13) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
(16) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
2017 |
Jan
(11) |
Feb
(10) |
Mar
(6) |
Apr
(4) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(4) |
Sep
(2) |
Oct
|
Nov
|
Dec
(11) |
2018 |
Jan
(8) |
Feb
(16) |
Mar
(6) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(5) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(9) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
|
Feb
|
Mar
(3) |
Apr
(12) |
May
(4) |
Jun
(12) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(2) |
Dec
(1) |
2022 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(68) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(9) |
Oct
(7) |
Nov
|
Dec
|
2023 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(11) |
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2024 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Thomas O. <tho...@or...> - 2024-09-20 00:22:56
|
Dear friends of mpg123, it would be great if anyone with a (modern) 64 bit ARM system could check if the recent addition (revision 5431) of PAC/BTI code from https://github.com/madebr/mpg123/pull/15 works. I do not have the resources to verify that myself. I've only checked that a normal ARM build still works. You need some bleeding-edge toolchain and set of libraries with branch protection enabled to properly test things. I hope things for normal builds still are unchanged. With ./configure CFLAGS='-mbranch-protection=standard' you should be able to see a trace of the newly added note section that marks our assembly code as safe for the branch protection stuff. We do not actually change active code, just tell the linker that it should trust it. A BTI-enabled build should show up like this: readelf -n ./src/libmpg123/.libs/libmpg123.so | grep -i bti Properties: AArch64 feature: BTI, PAC Alrighty then, Thomas |
From: <ano...@gm...> - 2024-09-06 16:11:18
|
A pull request by billatarm was opened at 2024-09-06 15:17:54+00:00. Please visit https://github.com/madebr/mpg123/pull/15 to give feedback and review the code. --- Enable Pointer Authentication Codes (PAC) and Branch Target Identification (BTI) support for ARM 64 targets. PAC works by signing the LR with either an A key or B key and verifying the return address. Since the assembly code does not push and pop the link register to the stack, and it remains in the register file, their is no need to sign the LR, so PAC is essentially just adding it to the GNU notes section for auditing purposes. BTI works by marking all call and jump positions with bti c and bti j instructions. If execution control transfers via an indirect branch or call to an instruction other than a BTI instruction, the execution is killed via SIGILL. For BTI to work, all object files linked for a unit of execution, whether an executable or a library must have the GNU Notes section of the ELF file marked to indicate BTI support. This is so loader/linkers can apply the proper permission bits (PROT_BRI) on the memory region. PAC can also be annotated in the GNU ELF notes section, but it's not required for enablement, as interleaved PAC and non-pac code works as expected since it's the callee that performs all the checking. Becuase the aarch64 assembly code does not make use of pushing the LR to the stack, only BTI targets were needed to be instrumented and the GNU notes section indicating support for BTU. Thus for PAC the only requirement was to mark the GNU notes section as supporting PAC. Testing was done under the following CFLAGS: 1. -mbranch-protection=none 2. -mbranch-protection=standard 3. -mbranch-protection=pac-ret 4. -mbranch-protection=pac-ret+b-key 5. -mbranch-protection=bti <!-- Please write a little about the why and how of this pull request A mail should automatically get sent to the mpg123-devel mailing list. Before submitting, please check the following: - [ ] Set target branch to `master` - [ ] Write a little text above --> --- patch details: - url: https://github.com/madebr/mpg123/pull/15 - patch: https://github.com/madebr/mpg123/pull/15.patch url details: - user name: billatarm - user url: https://github.com/billatarm |
From: Thomas O. <tho...@or...> - 2024-08-07 16:33:56
|
Hi there, mpg123 1.32.7 is coming out, with only some minor hygiene: 1.32.7 ------ - ports/cmake: Work around bug in CMake that does not detect FPU on Apple ARM CPUs (github PR 14). - Fix some laziness (func() to func(void)) for standards conformance. You can get it from https://mpg123.org/download.shtml as usual. Alrighty then, Thomas |
From: <ano...@gm...> - 2024-05-02 00:36:33
|
A pull request by madebr was opened at 2024-05-01 23:15:10+00:00. Please visit https://github.com/madebr/mpg123/pull/14 to give feedback and review the code. --- On Apple silicon, `cmake_host_system_information(RESULT HAVE_FPU QUERY HAS_FPU)` returns `HAVE_FPU=0`. I reported this [upstream](https://gitlab.kitware.com/cmake/cmake/-/issues/25950). Without a detected fpu, the build fails when `REAL_IS_FIXED` is defined, and neon is detected. https://github.com/madebr/mpg123/actions/runs/8916112597/job/24486953667#step:5:13 My fix moves the cpu arch detection earlier, and hard enables `HAVE_FPU` for apple arm64. As an extra, I added a patch that adds macos CI. --- patch details: - url: https://github.com/madebr/mpg123/pull/14 - patch: https://github.com/madebr/mpg123/pull/14.patch url details: - user name: madebr - user url: https://github.com/madebr |
From: <ano...@gm...> - 2024-04-06 11:06:00
|
A pull request by basicmaster was opened at 2024-04-06 10:57:49+00:00. Please visit https://github.com/madebr/mpg123/pull/13 to give feedback and review the code. --- Fixes a tiny typo. --- patch details: - url: https://github.com/madebr/mpg123/pull/13 - patch: https://github.com/madebr/mpg123/pull/13.patch url details: - user name: basicmaster - user url: https://github.com/basicmaster |
From: Thomas O. <tho...@or...> - 2024-04-04 18:12:41
|
Dear mpg123 folks, a little build system tweak arrives in the current mpg123 release. 1.32.6 ------ - build: Detect forced 64 bit offsets on a dual-mode system that used to default to 32 bits and drop ambiguous suffix-less symbols in that case. This avoids subtle ABI breakage (causing memory corruption) with existing binaries and instead has them fail during runtime linking. You trigger that when having -D_FILE_OFFSET_BITS=64 in your compiler flags during mpg123 build. If this does not mean anything to you … you might just ignore it. No new features, just less symbols in a library built in an environment with enforced large file support. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2024-02-17 15:38:47
|
Hi folks, some cleanup comes to you with mpg123 version 1.32.5: 1.32.5 ------ - build: -- CMake port uses CFLAGS for pulse/jack/tinyalsa properly now (bug 366). -- CMake port links libsyn123 with libm now (bug 370). - libmpg123: -- Fix --enable-portable (no usage of LFS_WRAP_NONE, bug 368). -- Fix dct36 wrapper usage for x86-64 and NEON. Stupid (bug 367) and also avoid returning void. -- Make ARM builds work with nagging (missing feature macros for std=c99). Grab it if you so desire from https://sourceforge.net/projects/mpg123/files/ or https://mpg123.org/download.shtml and have a good time. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2024-01-10 16:29:01
|
Hi all, some internal rearrangements and build system enhancements come with mpg123 1.32.4: 1.32.4 ------ - build: -- Reorganize shared headers, API headers into src/include. -- Use relative include paths, avoiding internal directories in CPPFLAGS except for config.h. -- Group C99 feature checks and make several standard headers mandatory. -- Get rid of SIZE_P, OFF_P and friends. -- Only enforce dummy module together with libout123, to be able to build individual modules using --disable-components logic. - out123: -- added --libversion - libmpg123: -- Avoid indirect branches into the assembly routines by using C wrappers also for dct36, relieving us of the need to care for bti / endbr instructions for control flow integrity. Get it from the usual places … Alrighty then, Thomas |
From: <ano...@gm...> - 2023-12-29 16:10:06
|
A pull request by JohannesKauffmann was opened at 2023-12-29 15:57:53+00:00. Please visit https://github.com/madebr/mpg123/pull/12 to give feedback and review the code. --- The function doesn't take a parameter, so don't pass it. Caught by Clang's -Wdeprecated-non-prototype: ``` ../src/streamdump.c:691:13: error: passing arguments to 'dump_close' without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] dump_close(sd); ^ ``` --- patch details: - url: https://github.com/madebr/mpg123/pull/12 - patch: https://github.com/madebr/mpg123/pull/12.patch url details: - user name: JohannesKauffmann - user url: https://github.com/JohannesKauffmann |
From: <ano...@gm...> - 2023-11-06 16:10:12
|
A pull request by i-garrison was opened at 2023-11-06 15:50:32+00:00. Please visit https://github.com/madebr/mpg123/pull/11 to give feedback and review the code. --- Allow building `mpg123` against installed `libmpg123` - add `programs` component to `configure.ac` - if building `libmpg123` is not enabled, find and use already installed `libmpg123` package; same for `libsyn123` and `libout123` - move a few shared internal headers from `src/libmpg123` to `src/include` to fix build against installed `libmpg123` package --- patch details: - url: https://github.com/madebr/mpg123/pull/11 - patch: https://github.com/madebr/mpg123/pull/11.patch url details: - user name: i-garrison - user url: https://github.com/i-garrison |
From: Thomas O. <tho...@or...> - 2023-10-02 14:50:40
|
The (up to now) final release of the quick regression fix succession of the 1.32.x series is out. It's a rough ride, but we're getting there. Maybe we've even arrived. 1.32.3 ------ - ports/cmake: Only enable modules with GetThreadErrorMode() on Windows. - compat: Define EOVERFLOW for ancient Windows toolchains. - libmpg123, libsyn123: always ifdef LFS_LARGEFILE_64 (not just if) - libsyn123: re-introduce _32 wrappers in addition to suffix-less ones (regression from 1.31, bug 363) Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2023-09-27 20:19:19
|
Hi all, please upgrade to mpg123 1.32.2 which yet again fixes things that I broke with 1.32.0. The CI and pre-release testing that we have is covering only part of what we got out there. Now we missed the case of -D_FILE_OFFSET_BITS=64 on 64 bit platforms, where the _64 symbols were missing. Also, the CMake build got some important fixes to complete what 1.32.0 should have had. Pleae just upgrade, for these fixes: 1.32.2 ------ - libmpg123: Re-introduce _64 symbols on native 64 bit offset platforms. This was a regression since 1.31 series. Sorry, too much cleanup, not enough testing. - build: -- Better O_LARGEFILE logic, avoiding redefintion. - ports/cmake: -- Require C99 (bug 360, among other points, thanks to Ozkan Sezer). -- Fix broken O_LARGEFILE logic (bug 360). -- Typo fix and cleanup, also manual SSE switch for Android on old x86 (bug 359). Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2023-09-26 06:42:52
|
There were some things amiss with the build system changes in the last release, most notably the man pages went missing. Further fixes mainly for the CMake build are also still in the works. Sorry for the fuss, but only the announced release got the testing we'd like to have had beforehand. 1.32.1 ------ - Include man pages again in tarball and install. We cannot avoid the empty man directory when disabling programs with autoconf. - Fix signal handler prototype, avoiding some justified warnings. - ports/cmake: -- Include CheckTypeSize, which seems to be needed sometimes (bug 357). -- Avoid O_LARGEFILE redefinition, logic closer to autoconf. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2023-09-23 22:04:28
|
Dear people who at least know what mpg123 is, version 1.32.0 got just released. Major points are the introduction of yet another API set to yet again fix the largefile support situation, where you can rely on fixed 64 bit integers instead of touching off_t, and fixing of the meaning of the offset for mpg123_seek() when working from the end. But there is more … please see the full list: 1.32.0 ------ - build: -- Move version handling out of configure.ac to ease other build systems. -- Include "fmt123.h" instead of <fmt123.h> in main API headers to make it more likely the correct one is included (at least gcc picks the one in the same directory as the including header first). -- All headers are build-independent now. -- Fix build for picky linkers by avoiding definition of wrap_getcpuflags() where it is not used (spurious linker error to non-exitent getcpuflags(), bug 353). -- Handle deprecation of C99 detection macro in autoconf 2.70. -- No use of AC_SYS_LARGEFILE anymore for explicit handling and differing choice for the libraries and frontend programs. -- Added --enable-portable and --disable-largefile to configure, removing the other largefile-related options. -- Added --disable-components --enable-libmpg123 to only build libmpg123 (and likewise --enable-libout123, --enable-libout123-modules, --enable-libsyn123) to autoconf build. CMake build has something similar with BUILD_PROGRAMS and BUILD_LIBOUT123, which leave only libmpg123 and libsyn123 if disabled). (bug 351) -- Consistent formatting of ./configure --help with AS_HELP_STRING(). - ports/Sony_PSP: removed - mpg123: -- Added --libversion. -- Added proper A-B looping with terminal control key 'o', renamed --pauseloop to --presetloop. -- Really get rid of mpg123_position() usage. (It was all lies before!) -- Fix terminal progress info when seeking in stopped mode (1.31 regression). -- Patch up interaction of output buffer with generic remote control, adding non-interruptible drain after P 3, and dropping buffer on QUIT. -- Uppercase some generic control replies for consinstency: SILENCE, PROGRESS, MUTE, UNMUTE - libmpg123, libout123, libsyn123: -- Bumped API version for version query functions. -- Replaced nearly all symbol renames with explicit INT123_ prefix declarations (intsym.h close to empty now). - libout123: -- Add sleep builtin output module (silent, but proper timing). - libsyn123: -- Introduced SYN123_PORTABLE_API for an API without off_t and ssize_t (see NEWS.libsyn123). - libmpg123: -- Internal I/O using explicit largefile support via off64_t, lseek64, fallback to plain 32 bit off_t. -- Added explicit 64 bit API with 64 suffix (mpg123_tell64(), not mpg123_tell_64()). This allows full avoidance of ambiguus off_t. The API is always using 64 bit integers, regardless of internal implementation. (bug 344) -- Introduced MPG123_PORTABLE_API for an API subset without off_t and ssize_t. -- Made mpg123_seek() and friends ignore offset sign for SEEK_END (always seeking towards beginning, assuming negative offset) to make lseek()-conforming usage possible. Seeking beyond the end never made sense, so no loss of valid functionality. - Overall use of INT123_strerror(), trying to use thread-safe strerror_l() if possible. Please get it from https://sourceforge.net/projects/mpg123/files/mpg123/1.32.0 or http://mpg123.org/download.shtml . Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2023-09-04 08:42:42
|
Second round! Am Tue, 22 Aug 2023 00:13:23 +0200 schrieb Thomas Orgis <tho...@or...>: > TL;DR: Test mpg123 snapshot on your platform and report breakage. Please. This is now the NEWS scheduled ever closer to a release: 1.32.0 ------ - build: -- Move version handling out of configure.ac to ease other build systems. -- Include "fmt123.h" instead of <fmt123.h> in main API headers to make it more likely the correct one is included (at least gcc picks the one in the same directory as the including header first). -- All headers are build-independent now. -- Fix build for picky linkers by avoiding definition of wrap_getcpuflags() where it is not used (spurious linker error to non-exitent getcpuflags(), bug 353). -- Handle deprecation of C99 detection macro in autoconf 2.70. -- No use of AC_SYS_LARGEFILE anymore for explicit handling and differing choice for the libraries and frontend programs. -- Added --enable-portable and --disable-largefile to configure, removing the other largefile-related options. -- Added --disable-components --enable-libmpg123 to only build libmpg123 (and likewise --enable-libout123, --enable-libsyn123) to autoconf build. CMake build has something similar with BUILD_PROGRAMS and BUILD_LIBOUT123, which leave only libmpg123 and libsyn123 if disabled). (bug 351) -- Consistent formatting of ./configure --help with AS_HELP_STRING(). - ports/Sony_PSP: removed - mpg123: -- Added --libversion. -- Added proper A-B looping with terminal control key 'o', renamed --pauseloop to --presetloop. -- Really get rid of mpg123_position() usage. (It was all lies before!) -- Fix terminal progress info when seeking in stopped mode (1.31 regression). -- Patch up interaction of output buffer with generic remote control, adding non-interruptible drain after P 3, and dropping buffer on QUIT. -- Uppercase some generic control replies for consinstency: SILENCE, PROGRESS, MUTE, UNMUTE - libmpg123, libout123, libsyn123: bumped API version for version query functions - libout123: -- Add sleep builtin output module (silent, but proper timing). - libsyn123: -- Introduced SYN123_PORTABLE_API for an API without off_t and ssize_t (see NEWS.libsyn123). - libmpg123: -- Internal I/O using explicit largefile support via off64_t, lseek64, fallback to plain 32 bit off_t. -- Added explicit 64 bit API with 64 suffix (mpg123_tell64(), not mpg123_tell_64()). This allows full avoidance of ambiguus off_t. The API is always using 64 bit integers, regardless of internal implementation. (bug 344) -- Introduced MPG123_PORTABLE_API for an API subset without off_t and ssize_t. -- Made mpg123_seek() and friends ignore offset sign for SEEK_END (always seeking towards beginning, assuming negative offset) to make lseek()-conforming usage possible. Seeking beyond the end never made sense, so no loss of valid functionality. There will be bugs, inevitably. The main point is the API changes that are supposed to stay for further releases: Anyone seeing an issue with those? Also, if anyone can spinup a current Windows system and test CMake with MSVC + yasm for assembly … we still got a mysterious build issue indicated by the git mirror: https://github.com/madebr/mpg123/actions/runs/6068446593/job/16461412092 That won't hold off the release, but having those CI actions run through would be nice. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2023-09-02 13:42:41
|
Am Sat, 2 Sep 2023 15:28:01 +0200 schrieb Thomas Orgis <tho...@or...>: > mpg123_seek(mh, 128, SEEK_END) > mpg123_seek(mh, -128, SEEK_END) > > could both do the same thing. The latter would've been a error > with current libmpg123. Turning errors into valid behaviour has > its risks, but in this case, I think it is sensible. May you verify if current trunk (or snapshot) apply this correctly? See updated https://mpg123.org/api/group__mpg123__seek.shtml . Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2023-09-02 13:28:17
|
[on-list again, again] Am 30. August 2023 23:11:34 MESZ schrieb Thomas Brand <to...@tr...>: >>> Eventually a "seek_compatibility" flag could be introduced. >> >> This would need to be opt-in, though. We could introduce a flag >> to fix SEEK_END behaviour. Or we could just document the state as-is >> and realize that it's a rare case with not much practical impact. >> >it's a hard decision. i don't know what's the best future-proof approach here. >opt-in sounds good, plus documentation .. >> Hm. Returning an error or silently (only by return value) limiting offset >> to the end. Both may make sense. I think it's simple after all. In a read-write library, seeking beyond the end makes sense. You can write there and enlarge the file. In a read-only library, only positions within the file make sense. Current mpg123 inverts the sign of an offset from SEEK_END, as I thought back then that it would be obvious to mean positive steps from the end back. Only one direction does make sense. So, what's the problem if I'd just ignore the sign of the SEEK_END argument? mpg123_seek(mh, 128, SEEK_END) mpg123_seek(mh, -128, SEEK_END) could both do the same thing. The latter would've been a error with current libmpg123. Turning errors into valid behaviour has its risks, but in this case, I think it is sensible. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2023-08-31 08:44:03
|
Am Tue, 29 Aug 2023 17:04:50 +0000 schrieb Thomas Brand <to...@tr...>: > I'm not sure how gapless is related to seek, I couldn't pin it down. It is related to seek, as it is concerned with exact sample offsets. Things like #ifdef GAPLESS else if(mh->end_os > 0) pos = SAMPLE_ADJUST(mh,mh->end_os) - sampleoff; #endif As only with gapless mode, things like the accurate sample count including padding from the encoder are considered. > PS, here the quick & dirty testcode: You had me wondering for a moment. Non-gapless mode is not tested … having it as an option stems from the time at that I did this one thing to mpg123, hack in gapless decoding. This was my addition and I of course wasn't sure how well it would work out. It was an option. It probably should not be an option anymore. To your testcase: Yes, seeking to 10 yields position 0. This is expected once you realize (or have better documentation indicating) that without the gapless machinery, libmpg123 seeking simply has no resolution below MPEG frames. With a normal MP3 file that has 1152 samples per frame, you should observe this: #seek_to result_gapless result_non-gapless 0 0 0 10 10 0 1151 1151 0 1152 1152 1152 The non-gapless mode can only advance in full MPEG frames. This is what mpg123 would do before I hacked in the gapless mode. Now we indeed could discuss if, after all the years, we should get rid of --disable-gapless. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2023-08-30 02:50:29
|
Am Tue, 29 Aug 2023 17:21:23 +0000 schrieb Thomas Brand <to...@tr...>: > To seek 10 samples before the end, I'd seek(-10, SEEK_END), but this > overshoots by 10 samples (length + 10). On the other hand, seek(10, > SEEK_END) will go to 10 samples before the end. I think this notion is > inverse to other uses of SEEK_END. Oh, great. Looking at lseek(2) and at my own documentation in mpg123.h, the behaviour indeed does not match the description. It's utterly wrong and you are the first person to notice. Damn. I have to think hard on how to best handle it. Just correcting the behaviour would break anyone relying on the existing. At the same time, precisely because you're the first one noticing, I _guess_ that you might be the only one trying to seek from the end on MPEG files so far. Having the reverse meaning compared to lseek really sucks. I don't have the solution right now for the next release, just a confirmation that you're right. Alrighty then, Thomas |
From: Thomas B. <to...@tr...> - 2023-08-29 17:21:30
|
Hi, I'm puzzled with mpg123_seek() when using SEEK_END. To seek 10 samples before the end, I'd seek(-10, SEEK_END), but this overshoots by 10 samples (length + 10). On the other hand, seek(10, SEEK_END) will go to 10 samples before the end. I think this notion is inverse to other uses of SEEK_END. Is it the expected behaviour? Unless I haven't overlooked something fundamental and my test is wrong, it should eventually be mentioned in the docs. Greetings Thomas |
From: Thomas B. <to...@tr...> - 2023-08-29 17:05:02
|
On 2023-08-21 22:13, Thomas Orgis wrote: > TL;DR: Test mpg123 snapshot on your platform and report breakage. > Please. > > > So, give > > https://mpg123.org/snapshot > > a spin. The full list of NEWS scheduled for the upcoming release > contains > some more points: > Hello, I've gave it a spin (x86_64, Linux) and everything looks good so far. Only a small set of functions are involved so it might not be representative. Something observed independently and most likely not related to the new snapshot is that when compile flag --enable-gapless=no is set, then mpg123_seek seems to not work. This also happens with for example 1.31.3. The effect is that a mpg123_seek(h, 10, SEEK_SET) will return 0. When --enable-gapless=no is not set, it will return 10, nothing else changed. I'm not sure how gapless is related to seek, I couldn't pin it down. Greetings Thomas PS, here the quick & dirty testcode: #include <stdio.h> #include <mpg123.h> #include <stdint.h> #include <inttypes.h> static mpg123_handle* mh; //===================================================== int main(int argc, char **argv) { long rate; int channels, format, err; int64_t offset=10; int64_t pos=0; mpg123_init(); mh = mpg123_new(NULL, NULL); mpg123_format_none (mh); format=mpg123_format(mh , 44100 , MPG123_STEREO , MPG123_ENC_FLOAT_32 ); err = mpg123_open(mh, argv[1]); if(err == MPG123_OK) { mpg123_getformat(mh, &rate, &channels, &format); pos=mpg123_seek(mh,offset,SEEK_SET); fprintf(stderr, "seek end return %" PRId64 "\n", pos); mpg123_close(mh); } else{fprintf(stderr, "Failed to open file: %s\n", mpg123_strerror(mh));} mpg123_exit(); } ./configure vs ./configure --enable-gapless=no |
From: Thomas O. <tho...@or...> - 2023-08-21 22:13:38
|
TL;DR: Test mpg123 snapshot on your platform and report breakage. Please. Dear all, the lengthy dicussion on bug 344 prompted some hefty rearrangements in the libmpg123 code and significant changes in the build. We have yet another overhaul of the largefile support. The primary code path is now formed by API that is fixed to offsets using int64_t and functions working with off_t (be it 32 bit or 64 bit) are bolted on top of that. This enables work with large files regardless of LFS in the libmpg123 build, which may be lacking in case of MSVC builds that simply don't do 64 bit off_t, by client code providing proper callbacks to mpg123_reader64( mpg123_handle *mh , int (*r_read) (void *, void *, size_t, size_t *) , int64_t (*r_lseek)(void *, int64_t, int) , void (*cleanup)(void*) ); Whatever tricks your platform needs to do proper I/O, you can implement them. I don't have to care. You can also define the macro MPG123_PORTABLE_API (same for libsyn123 and syn123.h with SYN123_PORTABLE_API) when including mpg123.h to skip defining any API that touches off_t (or ssize_t, for that matter). The library is now built using explicit _LARGEFILE64_SOURCE and lseek64(), if available. The standard autoconf largefile detection macro is not used anymore. So it could well be that something needs consideration on platform X. I might have assumed something that I shouldn't have. So, give https://mpg123.org/snapshot a spin. The full list of NEWS scheduled for the upcoming release contains some more points: 1.32.0 ------ - build: -- Move version handling out of configure.ac to ease other build systems. -- Include "fmt123.h" instead of <fmt123.h> in main API headers to make it more likely the correct one is included (at least gcc picks the one in the same directory as the including header first). -- All headers are build-independent now. -- Fix build for picky linkers by avoiding definition of wrap_getcpuflags() where it is not used (spurious linker error to non-exitent getcpuflags(), bug 353). -- Handle deprecation of C99 detection macro in autoconf 2.70. -- No use of AC_SYS_LARGEFILE anymore for explicit handling and differing choice for the libraries and frontend programs. -- Added --enable-portable and --disable-largefile to configure, removing the other largefile-related options. - ports/Sony_PSP: removed - mpg123: -- Added --libversion. -- Added proper A-B looping with terminal control key 'o', renamed --pauseloop to --presetloop. -- Really get rid of mpg123_position() usage. (It was all lies before!) -- Fix terminal progress info when seeking in stopped mode (1.31 regression). -- Patch up interaction of output buffer with generic remote control, adding non-interruptible drain after P 3, and dropping buffer on QUIT. -- Uppercase some generic control replies for consinstency: SILENCE, PROGRESS, MUTE, UNMUTE - libmpg123, libout123, libsyn123: bumped API version for version query functions - libout123: -- Add sleep builtin output module (silent, but proper timing). - libsyn123: -- Introduced SYN123_PORTABLE_API for an API without off_t and ssize_t (see NEWS.libsyn123). - libmpg123: -- Internal I/O using explicit largefile support via off64_t, lseek64, fallback to plain 32 bit off_t. -- Added explicit 64 bit API with 64 suffix (mpg123_tell64(), not mpg123_tell_64()). This allows full avoidance of ambiguus off_t. The API is always using 64 bit integers, regardless of internal implementation. (bug 344) -- Introduced MPG123_PORTABLE_API for an API subset without off_t and ssize_t. Alrighty then, Thomas |
From: Thomas B. <to...@tr...> - 2023-08-07 14:12:54
|
On 2023-08-06 11:27, Thomas Orgis wrote: > Am Sun, 06 Aug 2023 10:29:10 +0200 > schrieb Thomas Orgis <tho...@or...>: > >> I'll switch it over to a release branch, or generally have some >> version info in there. Sorry for the confusion. > > Or … actually … I kindof tried to prevent that confusion by this > preface: > > Note: This API doc is automatically generated from the current > development version that you can get via Subversion or as a > daily snapshot from http://mpg123.org/snapshot. There may be > differences (additions) compared to the latest stable release. > See NEWS.libmpg123, NEWS.libout123, NEWS.libsyn123, and the > overall NEWS file on libmpg123 versions and important changes > between them. > > I repaired the links to the NEWS files and spend a few minutes on > adding mpg123 release version info to make them more useful for library > feature lookup. See > > https://mpg123.org/trunk/NEWS.libmpg123 > > for an overview of what is available with which mpg123 release. The > version calls are scheduled for the next release series, 1.32. > > Really nice would be to have a tag on each symbol on which version it > appeared in. Maybe I'll script that into the doxygen stuff. Somehow I > like that better than N copies of the documentation. > Thanks for clarifying, it all makes sense now. Greetings Thomas |
From: Thomas O. <tho...@or...> - 2023-08-06 11:28:01
|
Am Sun, 06 Aug 2023 10:29:10 +0200 schrieb Thomas Orgis <tho...@or...>: > I'll switch it over to a release branch, or generally have some > version info in there. Sorry for the confusion. Or … actually … I kindof tried to prevent that confusion by this preface: Note: This API doc is automatically generated from the current development version that you can get via Subversion or as a daily snapshot from http://mpg123.org/snapshot. There may be differences (additions) compared to the latest stable release. See NEWS.libmpg123, NEWS.libout123, NEWS.libsyn123, and the overall NEWS file on libmpg123 versions and important changes between them. I repaired the links to the NEWS files and spend a few minutes on adding mpg123 release version info to make them more useful for library feature lookup. See https://mpg123.org/trunk/NEWS.libmpg123 for an overview of what is available with which mpg123 release. The version calls are scheduled for the next release series, 1.32. Really nice would be to have a tag on each symbol on which version it appeared in. Maybe I'll script that into the doxygen stuff. Somehow I like that better than N copies of the documentation. Alrighty then, Thomas |
From: Thomas O. <tho...@or...> - 2023-08-06 08:29:30
|
I see ... the documentation is generated from the svn trunk, not the released version. The current development cycle with lots of API additions (and only intermittend developer time) coming up is dragging along and makes documentation go out of sync for too long. I'll switch it over to a release branch, or generally have some version info in there. Sorry for the confusion. Alrighty then, Thomas |